Влияет ли размер поля на время запроса?

Question

Мой вопрос касается MySQL, но мне также интересно, как это влияет на другие базы данных. У меня есть несколько полей, которые varchar(255), но мой коллега настаивает, что если бы они были varchar(30) - или любого меньшего размера - тогда запросы выполнялись бы быстрее. Я не уверен, но если это так, я признаю это.

Answer 1

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

Для запросов SELECT сам оператор будет выполняться так же быстро в MySQL, и пока данные не становятся больше, чем в поле меньшего размера, они будут передаваться так же быстро. Если меньшее поле заставит вас хранить информацию в меньшем пространстве (вы бы использовали дополнительные 225 символов?), То вы получите быструю передачу в другие программы.

Для запросов INSERT размер поля не является проблемой, но использование полей переменной длины замедлит выполненный процесс. Вставки со строками фиксированной длины заметно быстрее (по крайней мере, в MySQL 5.0 и более ранних версиях).

Как правило, используйте размер, необходимый для данных. Если вы не знаете, нужно ли вам 255 или 30 символов, вы, вероятно, оптимизируете слишком рано. Являются ли большие поля данных узким местом? Ваша программа вообще страдает от проблем с производительностью базы данных? Сначала найдите свои узкие места, затем решите проблему с ними. Я предполагаю, что разница во времени, которую вы здесь смотрите, не важна для любой проблемы, которую вы пытаетесь решить.

Answer 2

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

Но во время запросов есть некоторые обстоятельства, когда MySQL преобразует VARCHAR в CHAR - и, следовательно, размер увеличивается до максимальной длины. Это происходит, например, когда MySQL создает временную таблицу во время некоторых операций JOIN или ORDER BY или GROUP BY.

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

Короткий ответ - да, он может иметь значение, используете ли вы VARCHAR (255) или VARCHAR (30). Так что определяйте максимальную длину столбца в соответствии с тем, что вам нужно, а не «большой» длиной, например, 255. Ради традиции.

Answer 3

Поскольку вы спрашивали о других базах данных ...

АБСОЛЮТНО влияет на время запроса.

В Oracle, когда данные перемещаются с сервера на клиент, это делается через буфер. Ничего революционного там нет. Количество строк, которые он помещает в этот буфер, зависит от максимального размера строки. Скажем, ваш запрос возвращает 4 столбца varchars. Если размер столбцов равен 100, и он должен быть 10, Oracle будет помещать в 10 раз меньше строк в каждом извлечении, чем это могло бы быть с определениями столбцов правильного размера. Это приводит к тому, что блоки перечитываются без необходимости. Это заставляет больше сетевого трафика, больше поездок туда и обратно.

В Oracle вы можете изменить размер буфера с помощью SET ARRAYSIZE. Попробуйте это когда-нибудь, сделайте запрос с одним размером, а затем сделайте это снова с 10% пространства. Вы увидите, что чтение увеличивается, сетевые поездки увеличиваются, а производительность снижается. Делать столбцы слишком большими - это все равно, что делать этот буфер слишком маленьким.

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

Помните:

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

Answer 4

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

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

Answer 5

Очень редко ширина столбца влияет на производительность запроса. Конечно, если вы используете большие объекты (BLOB, LONGBLOB, TEXT, LONGTEXT), существует вероятность того, что будет извлечено много данных. Это может повлиять на производительность, но это не обязательно. Это действительно влияет только на хранение. Если вам важен размер хранилища по типу данных, вы можете обратиться к http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html, чтобы увидеть подробности.

И еще раз повторим: размер хранилища данных не обязательно влияет на скорость запросов. Есть много других конструктивных соображений, которые будут влиять на скорость запросов. Разработка таблиц и связей, структуры ключей, индексов, архитектуры запросов и соединений и т. Д.

Answer 6

Все, что меньше VARCHAR (255), будет использовать один байт для хранения размера , поэтому VARCHAR (30) и VARCHAR (255) не будут иметь значения.

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

Даже если ваши данные непоследовательны, но, скажем, изменения в коэффициент, скажем, один байт, CHAR будет лучше, потому что вы все равно потратите один байт с информацией о размере.

Answer 7

Если вы используете только первые 30 символов, разница между varchar (30) и varchar (255) не будет (хотя будет разница с varchar (1000), которая будет взять дополнительный байт).

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