varchar（8000）よりもvarchar（500）に利点はありますか？

Question 1

私はこれをMSDNフォーラムとここで読みましたが、まだ明確ではありません。これは正しいと思います。Varchar（max）はテキストデータ型として格納されるため、欠点があります。したがって、フィールドが確実に8000文字未満になるとしましょう。データベーステーブルのBusinessNameフィールドのように。実際には、ビジネス名は常に500文字以内（数字を引っ張って）になります。たまたま私が遭遇するたくさんのvarcharフィールドは、8k文字のカウントに十分収まらないようです。

それで、そのフィールドをvarchar（8000）ではなくvarchar（500）にする必要がありますか？私がSQLについて理解していることから、これら2つの間に違いはありません。だから、人生を楽にするために、すべてのvarcharフィールドをvarchar（8000）として定義したいと思います。それには欠点がありますか？

関連：varcharカラムのサイズ（これが私の質問に答えたとは思わなかった）。

Question 2

処理の観点からは、varchar（8000）とvarchar（500）を使用しても違いはありません。フィールドが保持する必要がある最大長を定義し、varcharをその長さにすることは、「良い習慣」のようなものです。これは、データの検証を支援するために使用できるものです。たとえば、州の略称を2文字にするか、郵便番号を5または9文字にする。これは、データが他のシステムやフィールド長が重要なユーザーインターフェイス（メインフレームのフラットファイルデータセットなど）とやり取りするときに、以前より重要な区別でしたが、最近では、他の何よりも習慣になっていると思います。

Question 3

これにより違いが生じる可能性のある1つの例は、After Triggerを使用してテーブルに行バージョン情報を追加することを回避するパフォーマンスの最適化を妨げることです。

これはここのSQL Kiwiでカバーされています

保存されるデータの実際のサイズは重要ではありません。重要なのは潜在的なサイズです。

同様に、2016年以降にメモリ最適化テーブルを使用する場合、行の制限を超える可能性があるがペナルティを伴う可能性のあるLOB列または列幅の組み合わせを使用することが可能になりました。

（最大）列は常に行外に格納されます。その他の列の場合、テーブル定義のデータ行のサイズが8,060バイトを超える可能性がある場合、SQL Serverは最大の可変長列を行外にプッシュします。繰り返しますが、そこに格納するデータの量には依存しません。

これは、メモリの消費とパフォーマンスに大きな悪影響を与える可能性があります

列幅を過度に宣言すると大きな違いが生じる可能性があるもう1つのケースは、テーブルがSSISを使用して処理されるかどうかです。可変長（非BLOB）列に割り当てられたメモリは、実行ツリーの各行に対して固定され、列の宣言された最大長に基づいているため、メモリバッファの非効率的な使用につながる可能性があります（例）。SSISパッケージの開発者はソースよりも小さい列サイズを宣言できますが、この分析は前もって実行してそこで実施するのが最適です。

SQL Serverエンジン自体に戻ると、同様のケースとして、SORT操作に割り当てるメモリ許可を計算するときに、SQL Serverは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

スクリーンショット

Question 4

ベストプラクティス以外（BBlakeの回答）

DDLで最大行サイズ（8060）バイトとインデックス幅（900バイト）に関する警告が表示される
これらの制限を超えると、DMLは停止します
ANSI PADDING ONがデフォルトなので、空白の全負荷を格納してしまう可能性があります

Question 5

大規模な列にはいくつかの欠点がありますが、少しわかりにくく、少し遅れて気付く可能性があります。

INDEXで使用するすべての列-900バイトを超えてはなりません
ORDER BY句のすべての列が8060バイトを超えることはできません。これは一部の列にのみ適用されるため、理解するのが少し難しいです。詳細については、SQL 2008 R2の行サイズ制限を超えているを参照してください）
行の合計サイズが8060バイトを超えると、その行の「ページ溢れ」が発生します。これはパフォーマンスに影響を与える可能性があります（ページはSQLServerのアロケーションユニットであり、8000バイト+オーバーヘッドで固定されています。これを超えることは深刻ではありませんが、それは顕著であり、簡単にできる限り回避するようにしてください）
他の多くの内部データ構造、バッファー、および独自の変数とテーブル変数がすべてこれらのサイズをミラーリングする必要があります。サイズが大きすぎると、過剰なメモリ割り当てがパフォーマンスに影響を与える可能性があります

原則として、列幅は控えめにしてください。問題が発生した場合は、ニーズに合わせて簡単に拡張できます。後でメモリの問題に気付いた場合、後で幅の広い列を縮小することは、データを失うことなく不可能になり、どこから始めればよいかわからなくなります。

ビジネス名の例では、どこに表示するか考えてください。500文字分のスペースは本当にありますか？そうでない場合、それらをそのように保管しても意味がありません。http://en.wikipedia.org/wiki/List_of_companies_of_the_United_Statesにはいくつかの会社名がリストされており、最大は約50文字です。したがって、列の最大値として100を使用します。たぶん80にもっと似ているかもしれません。

Question 6

理想的には、それよりも小さく、適度なサイズ（500は適度なサイズではない）にして、データが大きくなりすぎて有用なエラーが送信されるときにクライアントの検証がキャッチすることを確認します。

varcharは実際には未使用のスペースのためにデータベース内のスペースを予約するつもりはありませんが、SQL Serverのバージョンでは、データベースの行が一部のバイト数よりも広いことを思い出して（正確な数を思い出さないでください）、実際に破棄しています適合しなかったデータはすべて。これらのバイトの特定の数は、SQL Serverの内部用に予約されています。