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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Помнить:

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

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

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

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

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