Един пример, в който това може да направи разлика, е, че може да предотврати оптимизация на производителността, която избягва добавянето на информация за версиите на редове към таблици с последващи задействания.
Това е разгледано от Пол Уайт тук
Действителният размер на съхраняваните данни е без значение – важен е потенциалният размер.
По същия начин, ако се използват оптимизирани за памет таблици от 2016 г., е възможно да се използват LOB колони или комбинации от ширини на колони, които потенциално биха могли да надхвърлят ограничението на редовете, но с наказание.
(Макс.) колоните винаги се съхраняват извън ред. За други колони, ако размерът на реда с данни в дефиницията на таблицата може да надвишава 8060 байта, SQL Server избутва най-голямата колона(и) с променлива дължина извън реда. Отново, това не зависи от количеството данни, които съхранявате там.
Това може да има голям отрицателен ефект върху консумацията на памет и производителността
Друг случай, при който прекомерното деклариране на ширините на колоните може да има голяма разлика, е дали таблицата някога ще бъде обработена с помощта на SSIS. Паметта, разпределена за колони с променлива дължина (не BLOB), е фиксирана за всеки ред в дървото на изпълнение и е според декларираната максимална дължина на колоните, което може да доведе до неефективно използване на буферите на паметта (пример). Въпреки че разработчикът на SSIS пакет може да декларира по-малък размер на колоната от източника, този анализ е най-добре да се направи предварително и да се приложи там.
Обратно в самия двигател на SQL Server подобен случай е, че при изчисляване на предоставената памет за разпределяне за SORT операции SQL Server приема, че varchar(x) колоните средно ще консумират x/2 байтове.
Ако повечето от вашия varchar колоните са по-пълни от това, което може да доведе до sort операции се прехвърлят към tempdb .
Във вашия случай, ако вашият varchar колоните са декларирани като 8000 байтове, но всъщност имат съдържание, много по-малко от това на вашата заявка ще бъде разпределена памет, която не изисква, което очевидно е неефективно и може да доведе до изчакване за предоставяне на памет.
Това е обхванато в част 2 от SQL Workshops Webcast 1, която можете да изтеглите от тук или вижте по-долу.
use tempdb;
CREATE TABLE T(
id INT IDENTITY(1,1) PRIMARY KEY,
number int,
name8000 VARCHAR(8000),
name500 VARCHAR(500))
INSERT INTO T
(number,name8000,name500)
SELECT number, name, name /*<--Same contents in both cols*/
FROM master..spt_values
SELECT id,name500
FROM T
ORDER BY number
SELECT id,name8000
FROM T
ORDER BY number
