Ширина стовпця VARCHAR SQL Server

Шукаючи по Інтернету, я знайшов суперечливі поради щодо того, чи є вплив на ефективність при вказівці надто широких стовпців 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

Які наслідки встановлення варчару (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) або більше. Порівняння ЧАР-ВАРЧАР із пов'язаної статті насправді не доречне. Хоча я згоден, ви не повинні вказувати більше місця, ніж ви впевнені, що вам потрібно, у багатьох випадках ви не знаєте, скільки саме місця вам буде потрібно. Тож будьте ліберальними з простором VARCHAR - я впевнений, що збільшення розміру полів потребує перебудови таблиці, а зменшення - простий оператор ALTER TABLE.