Важность длины varchar в таблице MySQL

Ответ 1

Нет, в том смысле, что если значения, которые вы сохраняете в этом столбце, всегда (скажем) меньше 50 символов, объявление столбца как varchar(50) или varchar(200) имеет ту же производительность.

Ответ 2

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

Ответ 3

VARCHAR идеально подходит для описываемой ситуации, потому что это означает "переменный символ" - предел, основанный на вашем примере, будет 200 символов, но что-нибудь меньшее будет принято и не будет заполнять выделенный размер столбца.

VARCHAR также занимает меньше места - значения сохраняются в виде однобайтового или двухбайтового префикса длины плюс данные. Префикс длины указывает количество байтов в значении. Столбец использует один байт длины, если значения не более 255 байт, два байта длины, если для значений может потребоваться больше 255 байт.

Для получения дополнительной информации о сравнении типов данных MySQL CHAR и VARCHAR см. эту ссылку.

Ответ 4

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

В вашем случае есть много утечек производительности, с которыми вы можете столкнуться: большие объединения почти невозможны с длинными столбцами varchar. Индексирование этих столбцов является настоящим убийцей. Ваш диск должен хранить данные. Одна страница памяти может содержать меньше строк, а сканирование таблиц будет намного медленнее. Кроме того, кэш запросов вряд ли поможет вам здесь.

Вы должны спросить себя: Сколько вставок в год может произойти? Какова средняя длина? Мне действительно нужно больше 200 символов, или я могу уловить это в своем интерфейсе приложений, даже проинформировав пользователей о максимальной длине? Могу ли я разбить таблицу на узкую для быстрой индексации и сканирования, а другую - для хранения дополнительных, менее часто требуемых данных расширения размера? Могу ли я набирать возможные данные varchar в категории и, таким образом, извлекать некоторые данные в несколько меньших, возможно, столбцов типа int или bool и сужать столбцы varchar таким образом?

Здесь вы можете многое сделать. Лучше всего перейти к первому предположению, а затем перепроектировать шаг за шагом, используя реальные измеренные данные о производительности. Удачи.

Ответ 5

Производительность? Нет. Дисковое хранилище? Да, но это дешево и обильно. Если ваша база данных не вырастет до терабайтного масштаба, вы, вероятно, все в порядке.

Ответ 6

Некоторые из вас ошибочно полагают, что varchar(200) занимает больше места на диске, чем varchar(20). Это не тот случай. Только когда вы выходите за пределы 255 символов, mysql использует дополнительный байт, чтобы определить длину данных поля varchar.

Ответ 7

Могут быть хиты производительности - но обычно не на уровне, который большинство пользователей заметили бы.

Когда размер каждого поля известен заранее, MySQL точно знает, сколько байтов находится между каждым полем/строкой и может перемещаться вперед, не читая все данные. Использование переменных символов уменьшает эту способность для оптимизации.

Влияет ли varchar на производительность из-за фрагментации данных?

Еще лучше, char vs varchar.

В большинстве случаев вам будет хорошо, но есть разница, и для крупномасштабных баз данных есть причины, по которым вы выбрали тот или иной.

Ответ 8

Будучи varchar, а не только char, размер основывается на внутреннем поле, чтобы указать его фактическую длину и строку. Поэтому использование varchar (200) не очень отличается от использования varchar (150), за исключением того, что у вас есть потенциал для хранения Больше.

И вы должны подумать о том, что происходит при обновлении, когда строка растет. Но если это редко, тогда все должно быть в порядке.

Ответ 9

в соответствии с именем типа данных предполагает, что это VARCHAR, то есть хранилище данных переменных символов, механизм mysql сам выделяет память, используемую в соответствии с хранимыми данными, поэтому по моим знаниям нет производительности.

Ответ 10

Вы должны попытаться просмотреть столбец varchar так же, как и столбец char в большинстве сценариев, и установить длину консервативно. Вам не всегда нужно думать о модификаторе var так сильно, как о чем-то, что влияет на принятие вами решения на максимальной длине. Это действительно следует рассматривать как подсказку производительности, вместо этого поставляемые строки будут иметь различную длину.

Это не директива, которая должна строго соблюдаться внутренними компонентами базы данных, ее можно полностью игнорировать. Однако позаботьтесь об этом, так как иногда реализация может протекать (например, с фиксированной длиной и отступом), даже если это не должно происходить в идеальном мире.

Если у вас есть varchar (255), то у вас нет гарантии, что по производительности он всегда будет вести себя иначе, чем char (255) при любых обстоятельствах.

Может показаться, что его легко установить на что-то, например 255, 65535 и т.д., В соответствии с рекомендациями, приведенными в руководстве по требованиям к хранилищу. Это создает впечатление, что любое значение между 0 (да, это вещь) и 255 будет иметь такое же влияние. Однако это не то, что может быть полностью гарантировано.

Требования к хранилищу, как правило, соответствуют действительности или являются хорошим показателем для достойных и зрелых систем постоянного хранения с точки зрения хранения строк. Это не такой сильный показатель для таких вещей, как индексы.

Иногда это сложный вопрос, сколько именно должен быть кусок строки, чтобы установить его на верхнюю границу, в пределах которой вы знаете, что она должна быть, но это никак не влияет. К сожалению, это часто остается для пользователя, и это действительно несколько произвольно. Вы не можете сказать, никогда не превышайте размер строки, потому что могут быть случаи, когда вы не совсем уверены.

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

Также следует учитывать набор символов, когда в игру вступают длина и производительность. Длина относится к этому, а не байты. Если, например, использовать utf8 (не MB4), тогда varchar (255) действительно varbinary (3 * 255). Трудно понять, как такие вещи будут действительно реализовываться без запуска тестов и углубленного изучения исходного кода/документации. Из-за этого существует чрезмерная длина, которая может оказать неожиданно раздутое воздействие. это относится не только к производительности. Если вам когда-нибудь понадобится изменить набор символов столбца varchar на больший, то вы можете в конечном итоге перейти к некоторому пределу без регресса, если вы позволите присутствовать безвозмездно длинным строкам, которых можно было бы избежать. Обычно это довольно нишевая проблема, но она все же возникает, в последнее время это была серьезная проблема с введением utf8mb4 для MySQL и индексов, которые имеют ограничение по длине ключа.

Если оказывается, что MAX (LENGTH (столбец)) всегда <64 (например, если было решено, что будет ограничение на ввод, который не соответствует определению столбца), но у вас есть varchar (255), тогда есть велика вероятность того, что в некоторых сценариях вы будете использовать в четыре раза больше места, чем необходимо.

Это может включать в себя:

• Различные двигатели, некоторые могут игнорировать это вообще.
• Размеры буфера, например, update или insert, возможно, должны были бы выделить полные 255 (хотя я не проверял исходный код, чтобы доказать это, это только гипотетически).
• Индексы, это будет сразу видно, если вы попытаетесь создать составной ключ из большого количества столбцов varchar (255).
• Промежуточные таблицы и, возможно, наборы результатов. Учитывая то, как работают транзакции, не всегда возможно использовать фактическую максимальную длину строк в столбце, в отличие от определенного предела.
• Внутренние прогностические оптимизации могут принимать максимальную длину в качестве входных данных.
• Изменения в версиях реализации базы данных.

Как показывает опыт, на самом деле нет необходимости, чтобы varchar был длиннее, чем он должен быть, в любом случае, из-за проблем с производительностью или нет, поэтому я рекомендую придерживаться этого, когда вы можете. Больше усилий для определения размера ваших данных, установления истинного предела или определения истинного предела с помощью вопросов/исследований - идеальный подход.

Когда вы не можете, если вы хотите сделать что-то вроде varchar (255) для случаев, когда есть сомнения, тогда я рекомендую заняться наукой. Это может заключаться в дублировании таблицы, уменьшении размера столбца var char, затем копировании данных в нее из оригинала и просмотре размера данных индекса/строки (также индексируйте столбец, также попробуйте использовать его в качестве первичного ключа, который может вести себя по-другому в InnoDB, поскольку строки упорядочены по первичному ключу). По крайней мере, таким образом, вы будете знать, если вы оказываете влияние на IO, которое, как правило, является одним из наиболее чувствительных узких мест. Тестирование использования памяти является более сложным, это трудно проверить исчерпывающим образом. Я бы порекомендовал протестировать потенциальные наихудшие случаи (запросы с большим количеством промежуточных результатов в памяти, проверка с помощью объяснения для больших временных таблиц и т.д.).

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

Ответ 11

Еще один момент, который можно упомянуть, состоит в том, что лучше использовать строки с фиксированной длиной, чем изменяющиеся. Например, лучше иметь столбцы типа char(n), bigint, date и т.д., Чем varchar. MySQL MyISAM механизм наилучшей производительности достигается при фиксированном размере строки.