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

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

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

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

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

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

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

Для Запросов на вставку размер поля не является проблемой, но использующий поля переменной длины замедлит сделанный процесс. ВСТАВЛЯЕТ со строками фиксированной длины, особенно быстрее (по крайней мере, в MySQL 5.0 и ранее).

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

Так как Вы спросили о других базах данных …

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

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

В Oracle можно изменить размер буфера с НАБОРОМ ARRAYSIZE. Попробуйте его когда-то, сделайте запрос с одним размером и затем сделайте это снова с 10% пространства. Вы будете видеть, что чтения повышаются, сетевые прохождения повышаются, и производительность понижается. Создание слишком больших столбцов точно так же, как делает тот буфер слишком маленьким.

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

Помните:

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

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

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

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

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

Очень редко будет производительность запросов влияния ширины столбца. Конечно, при использовании больших объектов (БЛОБЫ, LONGBLOBs, ТЕКСТЫ, LONGTEXTs), существует потенциал для большого количества данных, которые вытянут. Это могло возможно влиять на производительность, но она будет не обязательно. То действительно единственное устройство хранения данных влияния. Если Вы заботитесь о размере ресурса хранения типом данных, можно сослаться на http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html для наблюдения деталей.

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

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

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

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