Ширина столбца SQL Server VARCHAR

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

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

Верно ли утверждение, что The default is SET ANSI PADDING ON = potential for lots of trailing spaces ? Пока общая ширина строки меньше 8060, есть ли какие-то реальные проблемы с производительностью в столбцах VARCHAR с завышенными размерами?

Доказательство того, что ширина столбца имеет значение

The same goes for CHAR and VARCHAR data types. Don’t specify more characters in character columns that you need.

http://www.sql-server-performance.com/2007/datatypes/

• Length is a constraint on the data (like CHECK, FK, NULL etc)
• Performance when the row exceeds 8060 bytes
• Can not have unique constraint or index (key column width must be < 900)
• The default is SET ANSI PADDING ON = potential for lots of trailing spaces

Каковы последствия установки varchar (8000)?

Доказательство того, что ширина столбца не имеет значения

If you're talking about varchar and nvarchar then no, there is no penalty for allowing a higher field length.

/programming/7025996/overstating-field-size-in-database-design

The varchar datatype, by contrast, consumes only the amount of actual space used plus 2 bytes for overhead

http://sqlfool.com/content/PerformanceConsiderationsOfDataTypes.pdf

Вопрос может быть лучше сформулирован как:

«В чем преимущество чрезмерного указания максимальной длины столбца переменной длины?»

В целом, здесь мало преимуществ и несколько недостатков, как указывают различные связанные ответы. Помимо любых других проблем, учтите, что SQL Server не является открытым исходным кодом: существует множество «магических чисел» и эвристических методов, основанных на информации, предоставленной системе. Без доступа к исходному коду мы никогда не сможем быть полностью уверены в том, какое влияние может оказать эта практика.

В некоторых случаях , когда средняя длина столбца значительно превышает 50%, предполагаемый SQL Server при расчете разрешений на сортировку / хэш-память, вы можете увидеть улучшение производительности, переопределив максимальную длину. Это сомнительный обходной путь , и, вероятно, его следует применять только путем явного CASTили CONVERT(с комментариями!), А не путем изменения определения базового столбца. Иногда в любом случае предпочтительнее будет переписать запрос для сортировки ключей, а не целых строк.

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

SQL Server выполняет довольно хорошую работу в большинстве случаев, когда ему предоставляется точная и точная информация из метаданных. Скомпрометировать этот принцип для «удобства» мне кажется неразумным. Разумный подход выбрать максимальное значение длины, которое разумно в соответствии с фактическими данными , которые будут сохранены, а также любые изменения в обозримом будущем.

Как вы указали, до тех пор, пока размер строки не превышает 8060 (или независимо от того, какой максимум установлен), нет никакой разницы в производительности при использовании VARCHAR (30) или VARCHAR (255) или больше. Сравнение CHAR с VARCHAR из связанной статьи не совсем уместно. Хотя я согласен с тем, что вам не следует указывать больше места, чем вам нужно, во многих случаях вы не знаете, сколько места вам действительно нужно. Так что будьте либеральны с пространством VARCHAR - я уверен, что увеличение размера полей требует перестройки таблицы, в то время как уменьшение - простая инструкция ALTER TABLE.