これが違いを生む可能性がある1つの例は、アフタートリガーを使用してテーブルに行バージョン情報を追加することを回避するパフォーマンスの最適化を妨げる可能性があることです。
これはここでポールホワイトによってカバーされています
保存されるデータの実際のサイズは重要ではありません。重要なのは潜在的なサイズです。
同様に、2016年以降、メモリ最適化テーブルを使用している場合、LOB列または列幅の組み合わせを使用することが可能であり、行の制限を超える可能性がありますが、ペナルティがあります。
（最大）列は常に行外に格納されます。他の列の場合、テーブル定義のデータ行サイズが8,060バイトを超える可能性がある場合、SQLServerは最大の可変長列を行外にプッシュします。繰り返しになりますが、そこに保存するデータの量には依存しません。
これは、メモリ消費とパフォーマンスに大きな悪影響を与える可能性があります
列幅を過剰に宣言すると大きな違いが生じる可能性があるもう1つのケースは、テーブルがSSISを使用して処理されるかどうかです。可変長（非BLOB）列に割り当てられるメモリは、実行ツリーの各行に固定されており、列の宣言された最大長ごとにあるため、メモリバッファの非効率的な使用につながる可能性があります（例）。 SSISパッケージの開発者は、ソースよりも小さい列サイズを宣言できますが、この分析は事前に実行してそこで実施するのが最適です。
SQL Serverエンジン自体に戻ると、同様のケースは、SORTに割り当てるメモリ許可を計算する場合です。 操作SQLServerは、varchar(x)を想定しています 列は平均してx/2を消費します バイト。
ほとんどのvarchar 列は、これがsortにつながる可能性があるよりもいっぱいです tempdbにスピルする操作 。
あなたの場合、varchar 列は8000として宣言されます バイトですが、実際には、クエリに必要のないメモリが割り当てられるよりもはるかに少ない内容であるため、明らかに非効率的であり、メモリ許可の待機につながる可能性があります。
これについては、SQL Workshops Webcast 1のパート2で説明されています。ここからダウンロードするか、以下を参照してください。
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
