mysql - это - varchar пример




Рекомендации по длине столбца SQL varchar (5)

Всегда проверяйте у своего эксперта в области бизнеса. Если это вы, ищите отраслевой стандарт. Если, например, рассматриваемый домен является фамилией физического лица (фамилия), то для британского бизнеса я бы пошел в каталог стандартов данных Govtalk для личной информации и обнаружил, что фамилия будет от 1 до 35 символов ,

Каждый раз, когда вы настраиваете новую таблицу SQL или добавляете новый столбец varchar в существующую таблицу, мне интересно одно: лучшее значение для length .

Итак, скажем, у вас есть столбец с name type varchar . Итак, вы должны выбрать длину. Я не могу придумать имя> 20 символов, но вы никогда не узнаете. Но вместо того, чтобы использовать 20, я всегда округляю до следующего числа 2 ^ n. В этом случае я бы выбрал 32 как длину. Я делаю это, потому что с точки зрения компьютерного ученого число 2 ^ n выглядит для меня even больше, чем другие числа, и я просто предполагаю, что архитектура под ними может обрабатывать эти числа немного лучше других.

С другой стороны, сервер MSSQL, например, устанавливает значение длины по умолчанию равным 50, когда вы решите создать столбец varchar. Это заставляет меня думать об этом. Почему 50? это просто случайное число, или на основе средней длины столбца, или что?

Это также может быть - или, возможно, - что разные реализации SQL-серверов (например, MySQL, MSSQL, Postgres, ...) имеют разные наилучшие значения длины столбца.


Всякий раз, когда я настраиваю новую таблицу SQL, я чувствую то же самое, что 2 ^ n является более «четным» ... но для подведения итогов ответов здесь нет существенного влияния на пространство памяти просто путем определения varchar (2 ^ n) или даже varchar (MAX).

Тем не менее, вы должны все же предвидеть потенциальные последствия для хранения и производительности при установке максимального значения varchar (). Например, предположим, что вы создаете столбец varchar (MAX) для хранения описаний продуктов с полнотекстовой индексацией. Если 99% описаний имеют длину всего 500 символов, а затем вы получаете кого-то, кто заменяет указанные описания на статьи в википедии, вы можете заметить непредвиденные значительные проблемы с хранением и производительностью.

Еще одна вещь, которую следует рассмотреть у Билла Карвина :

Существует одно возможное влияние на производительность: в MySQL временные таблицы и таблицы MEMORY хранят столбец VARCHAR в виде столбца фиксированной длины, отложенного до максимальной длины. Если вы сконструируете столбцы VARCHAR намного больше, чем вам нужен наибольший размер, вы будете потреблять больше памяти, чем вам нужно. Это влияет на эффективность кеша, скорость сортировки и т. Д.

В принципе, просто придумайте разумные бизнес-ограничения и ошибки на немного большем размере. Как уже отмечалось, фамилии в Великобритании обычно составляют от 1 до 35 символов. Если вы решите сделать это varchar (64), вы на самом деле ничего не обидите ... если вы не сохранили фамилию этого парня, которая, как говорят, насчитывает до 666 символов. В этом случае, может быть, varchar (1028) имеет больше смысла.

И в случае, если это полезно, вот что может выглядеть varchar 2 ^ 5 до 2 ^ 10, если оно заполнено:

varchar(32)     Lorem ipsum dolor sit amet amet.

varchar(64)     Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie

varchar(128)    Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie
                vestibulum massa. Nullam dignissim elementum molestie. Vehiculas

varchar(256)    Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie
                vestibulum massa. Nullam dignissim elementum molestie. Vehiculas
                velit metus, sit amet tristique purus condimentum eleifend. Quis
                que mollis magna vel massa malesuada bibendum. Proinde tincidunt

varchar(512)    Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie
                vestibulum massa. Nullam dignissim elementum molestie. Vehiculas
                velit metus, sit amet tristique purus condimentum eleifend. Quis
                que mollis magna vel massa malesuada bibendum. Proinde tincidunt
                dolor tellus, sit amet porta neque varius vitae. Seduse molestie
                lacus id lacinia tempus. Vestibulum accumsan facilisis lorem, et
                mollis diam pretium gravida. In facilisis vitae tortor id vulput
                ate. Proin ornare arcu in sollicitudin pharetra. Crasti molestie

varchar(1024)   Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donecie
                vestibulum massa. Nullam dignissim elementum molestie. Vehiculas
                velit metus, sit amet tristique purus condimentum eleifend. Quis
                que mollis magna vel massa malesuada bibendum. Proinde tincidunt
                dolor tellus, sit amet porta neque varius vitae. Seduse molestie
                lacus id lacinia tempus. Vestibulum accumsan facilisis lorem, et
                mollis diam pretium gravida. In facilisis vitae tortor id vulput
                ate. Proin ornare arcu in sollicitudin pharetra. Crasti molestie
                dapibus leo lobortis eleifend. Vivamus vitae diam turpis. Vivamu
                nec tristique magna, vel tincidunt diam. Maecenas elementum semi
                quam. In ut est porttitor, sagittis nulla id, fermentum turpist.
                Curabitur pretium nibh a imperdiet cursus. Sed at vulputate este
                proin fermentum pretium justo, ac malesuada eros et Pellentesque
                vulputate hendrerit molestie. Aenean imperdiet a enim at finibus
                fusce ut ullamcorper risus, a cursus massa. Nunc non dapibus vel
                Lorem ipsum dolor sit amet, consectetur Praesent ut ultrices sit

Наилучшее значение - это то, которое подходит для данных, определенных в базовом домене.

Для некоторых доменов VARCHAR(10) подходит для атрибута Name , для других доменов VARCHAR(255) может быть лучшим выбором.


Никакая СУБД, которую я знаю, не имеет никакой «оптимизации», которая сделает VARCHAR с длиной 2^n лучше, чем одна с max длиной, которая не равна 2.

Я думаю, что ранние версии SQL Server фактически обрабатывали VARCHAR длиной 255 по сравнению с версией с максимальной максимальной длиной. Я не знаю, все ли так.

Для почти всех СУБД фактическое требуемое хранилище определяется только количеством символов, которые вы вставляете в него, а не max длиной, которую вы определяете. Таким образом, с точки зрения хранения (и, скорее всего, производительности тоже), не имеет значения, объявляете ли вы столбец как VARCHAR(100) или VARCHAR(500) .

Вы должны увидеть max длину для столбца VARCHAR как своего рода ограничение (или бизнес-правило), а не техническую / физическую вещь.

Для PostgreSQL лучше всего использовать text без ограничения длины и CHECK CONSTRAINT который ограничивает количество символов в зависимости от вашего бизнеса.

Если это требование изменится, изменение контрольного ограничения происходит намного быстрее, чем изменение таблицы (поскольку таблицу не нужно переписывать)

То же самое можно применить и к Oracle, и к другим - в Oracle вместо text будет использоваться VARCHAR(4000) .

Я не знаю, существует ли разница в физическом хранилище между VARCHAR(max) и, например, VARCHAR(500) в SQL Server. Но, по-видимому, есть влияние производительности при использовании varchar(max) по сравнению с varchar(8000) .

См. Эту ссылку (опубликовано Erwin Brandstetter в качестве комментария)

Изменить 2013-09-22

Что касается комментария Бинауна:

В версиях Postgres до 9.2 (которые не были доступны, когда я написал исходный ответ) изменение в определении столбца переписало всю таблицу, см. here . С 9.2 это уже не так, и быстрый тест подтвердил, что увеличение размера столбца для таблицы с 1,2 миллионами строк действительно занимает всего 0,5 секунды.

Для Oracle это, по-видимому, также верно, судя по тому, как требуется изменить колонку varchar большой таблицы. Но я не мог найти никаких ссылок на это.

Для MySQL в руководстве говорится: « В большинстве случаев ALTER TABLE создает временную копию исходной таблицы ». И мои собственные тесты подтверждают, что: выполнение ALTER TABLE на таблице с 1,2 миллионами строк (так же, как в моем тесте с Postgres), чтобы увеличить размер столбца, заняло 1,5 минуты. Однако в MySQL вы не можете использовать «обходной путь» для использования ограничения проверки, чтобы ограничить количество символов в столбце.

Для SQL Server я не мог найти четкую инструкцию по этому поводу, но время выполнения для увеличения размера столбца varchar (опять же таблица из 1,2 миллиона строк сверху) указывает, что переписывание не происходит.

Редактировать 2017-01-24

Кажется, я был (по крайней мере частично) ошибочным в отношении SQL Server. См. Этот ответ от Aaron Bertrand, который показывает, что заявленная длина столбцов nvarchar или varchar имеет огромное значение для производительности.


VARCHAR(255) и VARCHAR(2) занимают ровно столько же места на диске! Поэтому единственная причина ограничить это, если у вас есть конкретная потребность в ее уменьшении. В противном случае сделайте все 255.

В частности, при сортировке более крупный столбец занимает больше места, поэтому, если это ущемляет производительность, вам нужно беспокоиться об этом и сделать их меньше. Но если вы только когда-либо выбираете 1 строку из этой таблицы, вы можете просто сделать все 255, и это не имеет значения.

См .: Каковы оптимальные размеры varchar для MySQL?







postgresql