Как узнать длину поля в SQL.
Здравствуйте, дорогие читатели. Мы продолжаем изучать SQL и сегодня разберемся, как узнать длину строки в SQL.
Описание
Иногда бывает полезно узнать длину какой-то строки в поле. Конечно, можно выбрать значение, а потом в PHP посчитать его длину, но тогда это будет выполняться дольше, да и не нужно это, ведь в SQL уже есть готовая функция для данной операции.
Название функции, что логично, — LEN()
Пример
К примеру, у нас есть табличка с какими-то полями и одно поле — имя пользователя.
Нам нужно узнать, какое самое длинное имя у пользователя, но, чтобы это сделать, длину имени нужно вычислить. А делается это вот таким образом:
SELECT name, LEN(name) AS length FROM users;
В результате мы получим табличку, где будет имя пользователя в первом столбце и длина имени — во втором.
Как видите, использовать данную функцию очень просто и не нужно никаких PHP.
Спасибо за внимание!
Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!
Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.
Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления
Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.
Порекомендуйте эту статью друзьям:
Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):
Она выглядит вот так:
Комментарии ( 1 ):
У меня выдало ошибку #1305. Погуглив я разузнал, что, в зависимости от версии phpMyAdmin или чего-то там другого, функция LEN() может не работать. Вместо неё нужно использовать LENGTH(). Такие вот дела.
Для добавления комментариев надо войти в систему.
Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.
Функция LENGTH
Функция LENGTH используется для подсчета количества символов в строках.
Вместо LENGTH можно использовать следующие названия: OCTET_LENGTH, CHAR_LENGTH, CHARACTER_LENGTH.
Существует также функция BIT_LENGTH, которая возвращает длину в битах.
Синтаксис
Примеры
Все примеры будут по этой таблице workers, если не сказано иное:
| id айди |
name имя |
|---|---|
| 1 | Дмитрий |
| 2 | Кирилл |
| 3 | Владимир |
Пример
В данном примере создается дополнительное поле, которое содержит длину поля name:
SQL запрос выберет следующие строки:
| id айди |
name имя |
length длина строки |
|---|---|---|
| 1 | Дмитрий | 7 |
| 2 | Кирилл | 6 |
| 3 | Владимир | 8 |
Пример
В данном примере с помощью условия WHERE выбираются только те записи, в которых длина поля name больше или равна 7:
SQL запрос выберет следующие строки:
| id айди |
name имя |
length длина строки |
|---|---|---|
| 1 | Дмитрий | 7 |
| 3 | Владимир | 8 |
Пример
Конечно, не обязательно делать поле length, чтобы применить функцию LENGTH в условии:
DataGinger.com
SQL Server – How to Calculate Length and Size of any field in a SQL Table
Recently I came across a situation where queries are loading extremely slow from a table. After careful analysis we found the root cause being, a column with ntext datatype was getting inserted with huge amounts of text content/data. In our case DATALENGTH T-SQL function came real handy to know the actual size of the data in this column.
According to books online, DATALENGTH (expression) returns the length of the expression in bytes (or) the number of bytes SQL needed to store the expression which can be of any data type. From my experience this comes very handy to calculate length and size especially for LOB data type columns ( varchar , varbinary , text , image , nvarchar , and ntext ) as they can store variable length data. So, unlike LEN function which only returns the number of characters, the DATALENGTH function returns the actual bytes needed for the expression.
Here is a small example:
If your column/expression size is too large like in my case, you can replace DATALENGTH(Name) with DATALENGTH(Name)/1024 to convert to KB or with DATALENGTH(Name)/1048576 to get the size in MB.
Узнать размер колонки
Для того, чтобы узнать размер всей бд, или, например, одной таблицы, у нас есть команда ‘sp_spaceused’. Но если пойти дальше, то возникает вопрос: а как получить статистику по полям? Как узнать, в каком поле (колонке) в таблице содержатся самые тяжёлые данные, а в каком самые легкие?
Вопрос не столько теоретический, сколько практический: есть огромная база, которую надо проанализировать (постепенно погружаюсь в Data-Mining).
Используйте функцию DATALENGTH()
В следующем примере находится длина столбца ProductName в таблице MyOrderTable.
Как узнать, в каком поле (колонке) в таблице содержатся самые тяжёлые данные, а в каком самые легкие?
Вас интересует размер в байтах, занимаемый тем или иным столбцом на диске (видимо так, раз вы упомянули sp_spaceused )?
Не уверен, что возможно определить его точно. Точно можно узнать, сколько страниц (блоков по 8Кб, которыми SqlServer хранит данные) занимают данные всей таблицы (или индекса).
Месту на диске, отведенному под хранение конкретного столбца, по-видимому можно дать лишь некоторую оценку (которая, впрочем, не всегда будет адекватной). И с datalength не совсем всё просто. Далее несколько подробнее.
за основу оценки.
Во-первых. Кроме собственно данных столбца всегда есть дополнительная служебная информация, которая может иметь отношение к столбцу, но её объем между столбцами логически может делиться непропорционально их количеству в таблице (например данные заголовка строки). Т.е. оценку размера /*1*/ следует воспринимать как «не менее чем».
Чем меньше в таблице столбцов, и чем короче запись, тем больше издержки на служебные данные, тем, соответственно, дальше оценка /*1*/ от реальности. Так, для таблицы с одним коротким столбцом полный размер данных (с учётом служебной информации) может значительно превосходить «логический» размер данных самого столбца. Сравните, например, для таблицы
результат, возвращаемый запросом /*1*/ с тем, что покажет sp_spaceused .
Во-вторых. Значение, возвращаемое datalength не всегда соответствует действительности. В частности, если datalength([Column]) возвращает NULL , то физически это может быть вовсе не ноль.
Дело в том, что типы столбцов делятся на fixed-length (напр. int , char(20) , datetime2(0) , uniqueidentifier , и т.п.) и variable-length (напр. varbinary(64) , nvarchar(30) и т.п.). И если для variable-length оценка /*1*/ приблизительно справедлива, то для fixed-length столбцов резервируется место для хранения значения, даже если само значение NULL .
Т.е. для fixed-length столбцов оценку /*1*/ следует скорректировать, используя вместо NULL (если они возможны) какое-либо непустое значение, соответствующее типу столбца (например 0 для int ):
Также нужно учитывать, что для столбцов типа bit возвращаемое datalength значение равно 1. Однако если в таблице (или индексе) несколько bit столбцов, то SqlServer объединяет их по 8 в 1 байт.
Также столбцы могут быть sparse , что означает 0 байт на хранение NULL (даже для fixed-length), но плюс 4 дополнительных байта на хранение значения, если оно не NULL :
В-третьих. Если столбец не просто присутствует в таблице, а ещё и участвует в индексах, то он «утяжеляется» кратно количеству индексов, в которых он участвует. Если столбец является ключевым в кластерном индексе, то нужно прибавить оценку кратную количеству всех некластерных индексов (т.к. в leaf-level страницах некластерных индексов содержатся значения ключей кластерного индекса). Так в таблице
самым «тяжёлым» скорее всего окажется вовсе не UID столбец, а PK_ID , т.к. (помимо участия в кластерном первичном ключе) значения PK_ID будут присутствовать ещё в 10-ти некластерных индексах.
Следует учесть также, что если некластерный индекс является фильтрованным индексом, то соответствующую оценку ( /*1*/ , /*2*/ или /*3*/ ) нужно взять не по всей таблице, а по строкам, соответствующим фильтру такого индекса.
В-четвертых (относится к Enterprise edition). Если применяется сжатие строк или страниц таблицы
то оценки с помощью datalength перестают быть адекватными и фактор «не менее чем» перестаёт работать.
Сравните для таблиц
значения оценки размера столбца с помощью datalength c тем, что покажет sp_spaceused . Для первой таблицы «показания» datalength и sp_spaceused будут близки (т.к. строка таблицы «широкая» и объем служебной информации сказывается мало), а для второй будут расходиться очень сильно.
В-пятых. Всё что было сказано до этого момента справедливо для SqlServer 2008. В более поздних версиях появились COLUMNSTORE индексы, которые, из-за особенностей своего устройства, могут хранить данные в существенно сжатом виде. Для них оценка размера столбца с помощью datalength также может давать неадекватный результат. Если для таблицы
сравнить показания sp_spaceused с datalength , то опять можно наблюдать сильное расхождение.
Полагаю, что данный список факторов, которые следует учитывать при оценке места, занимаемого тем или иным столбцом, не исчерпывающий.