Одним із прикладів, коли це може змінити ситуацію, є те, що це може запобігти оптимізації продуктивності, яка дозволяє уникнути додавання інформації про версії рядків до таблиць із тригерами після.
Тут висвітлено SQL Kiwi
Фактичний розмір збережених даних несуттєвий - важливий саме потенційний розмір.
Подібним чином, якщо з 2016 року використовуються таблиці, оптимізовані для пам'яті, можна використовувати стовпці LOB або комбінації ширини стовпців, які потенційно можуть перевищувати обмеження вростання, але із штрафом.
(Макс.) Стовпці завжди зберігаються поза рядами. Для інших стовпців, якщо розмір рядка даних у визначенні таблиці може перевищувати 8 060 байт, SQL Server витісняє найбільші стовпці змінної довжини поза рядками. Знову ж таки, це не залежить від кількості даних, які ви там зберігаєте.
Це може мати великий негативний вплив на споживання пам'яті та продуктивність
Інший випадок, коли надмірна декларація ширини стовпців може мати велике значення, - якщо таблиця коли-небудь буде оброблена за допомогою SSIS. Пам'ять, виділена для стовпців змінної довжини (не BLOB), фіксується для кожного рядка у дереві виконання і відповідає заявленій максимальній довжині стовпців, що може призвести до неефективного використання буферів пам'яті (приклад) . Хоча розробник пакета SSIS може оголосити менший розмір стовпця, ніж джерело, цей аналіз найкраще робити заздалегідь і застосовувати там.
Повертаючись до самого механізму SQL Server, схожий випадок полягає в тому, що при обчисленні дози пам'яті для виділення SORTоперацій SQL Server припускає, що varchar(x)стовпці в середньому споживають x/2байти.
Якщо більшість ваших varcharстовпців заповнені, це може призвести до sortпереливання операцій tempdb.
У вашому випадку, якщо ваші varcharстовпці оголошені як 8000байти, але насправді мають вміст набагато менше, ніж для вашого запиту буде виділено пам'ять, яка йому не потрібна, що, очевидно, неефективно і може призвести до очікування надання грантів.
Це висвітлено у Частині 2 веб-трансляції SQL Workshop 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
