SQL varchar 列の長さに関するベストプラクティス [closed] 質問する

私が知る限り、長さが 2 の累乗でない長VARCHARさのもの2^nよりも、長さが 2 の累乗であるもののパフォーマンスが向上するような「最適化」を備えた DBMS はありません。max

初期の SQL Server バージョンでは、長さが 255 の文字列は、最大長がそれより大きい文字列とは実際には異なる方法で処理されていたと思いますVARCHAR。これが現在でも当てはまるかどうかはわかりません。

ほとんどすべての DBMS では、実際に必要なストレージは、定義した長さではなく、格納する文字数によってのみ決まります。したがって、ストレージの観点から (そしておそらくパフォーマンスの観点からも)、列を と宣言するかとmax宣言するかは違いはありません。VARCHAR(100)VARCHAR(500)

max列に指定される長さは、VARCHAR技術的/物理的なものではなく、一種の制約 (またはビジネス ルール) として考える必要があります。

PostgreSQL の場合、最適な設定は、text長さの制限なしで、CHECK CONSTRAINTビジネス要件に応じて文字数を制限する を使用することです。

要件が変わった場合、チェック制約を変更する方がテーブルを変更するよりもはるかに高速です（テーブルを書き換える必要がないため）。

同じことが Oracle や他のサービスにも当てはまります。Oracle では、 thoughVARCHAR(4000)の代わりに になりますtext。

VARCHAR(max)たとえば SQL Server でと の間に物理的なストレージの違いがあるかどうかはわかりません。しかし、と比較するVARCHAR(500)と を使用するとパフォーマンスに影響があるようです。varchar(max)varchar(8000)

見るこのリンク(Erwin Brandstetter がコメントとして投稿)

編集 2013-09-22

bigown さんのコメントについて:

9.2より前のPostgresバージョン（私が最初の回答を書いた時点では利用できませんでした）では、列定義を変更するとテーブル全体が書き換えられました。例を参照してください。ここ9.2 以降では、この状況はなくなり、簡単なテストで、120 万行のテーブルの列サイズを増やすのに実際に 0.5 秒しかかからないことが確認されました。

大きなテーブルの列を変更するのにかかる時間から判断すると、Oracle の場合もこれは当てはまるようですvarchar。しかし、それに関する参考資料は見つかりませんでした。

MySQLの場合マニュアルにはこう書いてある「ほとんどの場合、ALTER TABLE元のテーブルの一時的なコピーを作成します」。また、私自身のテストでは、ALTER TABLE120 万行のテーブル (Postgres でのテストと同じ) で を実行して列のサイズを増やすのに 1.5 分かかったことが確認されています。ただし、MySQL では、チェック制約を使用して列の文字数を制限する「回避策」は使用できません。

SQL Server については、これに関する明確な説明は見つかりませんでしたが、varchar列のサイズを増やすための実行時間 (前述の 120 万行のテーブルの場合) は、書き換えが行われないことを示しています。

編集 2017-01-24

SQL Serverについては（少なくとも部分的に）間違っていたようです。アーロン・バートランドからの回答nvarcharこれは、宣言された列の長さがvarcharパフォーマンスに大きな違いをもたらすことを示しています。