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

У меня есть таблица MySQL, в которой строки вставляются динамически. Поскольку я не могу быть уверен в длине строк и не хочу, чтобы они обрезались, я делаю их varchar (200), который обычно намного больше, чем мне нужно. Есть ли большой удар по производительности, если дать полю varchar намного большую длину, чем необходимо?

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

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

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

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

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

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

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

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

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

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

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

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

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

Приводит ли varchar к снижению производительности из-за фрагментации данных?

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

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

Являясь varchar, а не просто char, размер зависит от внутреннего поля, указывающего его фактическую длину и самой строки. Таким образом, использование varchar (200) не сильно отличается от использования varchar (150), за исключением того, что у вас есть возможность хранить больше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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