SQL ServerのVARCHAR列幅

Webを検索すると、過度に広いVARCHAR列を指定したときにパフォーマンスに影響があるかどうか、たとえばVARCHAR（30）がおそらくする場合のVARCHAR（255）について、矛盾したアドバイスが見つかりました。

行全体が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

varchar（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）以上を使用してもパフォーマンスの違いはありません。リンクされた記事のCHARとVARCHARの比較は、実際には関係ありません。必要だと確信している以上のスペースを指定してはいけないことに同意しますが、多くの場合、実際にどれだけのスペースが必要かはわかりません。したがって、VARCHARスペースには寛大です-フィールドのサイズを大きくするにはテーブルの再構築が必要ですが、小さくするには単純なALTER TABLEステートメントが必要です。