5

重複の可能性：
varchar（8000）よりもvarchar（500）の方が有利ですか？

私は現在、varchar（50）を使用して多数の列を持つテーブルに取り組んでいます。データは、50文字を超える列に挿入する必要があるため、これらの列の列サイズを50から128に変更する必要があります。これは、列が多数あるため、個々の列を変更するのに時間の無駄です。

そこで、私は自分のチームに、すべての列をvarchar（128）に変更しないように提案しました。一部のチームメイトは、これにより、選択および結合操作中にパフォーマンスが低下する可能性があると主張しました。

現在、私はデータベースの専門家ではありませんが、varchar50からvarchar128に移行しても、パフォーマンスが大幅に低下することはないと思います。

PS-これらの列には、名前、名前、住所の種類のデータはありません。

4

4 に答える 4

5

varchar(50)そしてvarchar(128)、すべての観点からほぼ同じように動作します。ストレージサイズは、50文字未満の値でも同じです。これらは、型変換の問題なしで交換可能に結合（varchar(50)結合varchar(128)）できます（つまり、インデックスは結合内varchar(50)の列を検索できますvarchar(128)）。同じことがWHERE述語にも当てはまります。SQL Server 2012より前では、varchar列のサイズを大きくすることは非常に高速なメタデータのみの操作でしたが、SQL Server 2012以降では、この操作は、説明されているものと同様に、特定の条件下ではデータの更新ごとに遅いサイズになる可能性があります。 null許容列を追加すると、テーブル全体が更新される可能性があります。

列の長さを変更すると、いくつかの問題が発生する可能性があります。

  • 予期しないサイズ値の処理によるアプリケーションの問題。ネイティブのものは、不適切にコード化された場合、バッファサイズの問題に遭遇する可能性があります（つまり、サイズが大きいとバッファオーバーフローが発生する可能性があります）。管理対象アプリで深刻な問題が発生する可能性は低いですが、画面やレポートの列幅に値が収まらないなどの小さな問題が発生する可能性があります。
  • 挿入または更新時に値を切り捨てることによるT-SQLエラー
  • T-SQLのサイレント切り捨てが発生し、誤った値が生成されます（たとえば、ストアドプロシージャで宣言された@variables varchar(50)）
  • 最大行サイズや最大インデックスサイズなどの制限に達する可能性があります。例えば。現在、タイプが8列の複合インデックスがあり、最大インデックスサイズの900を超えて、警告がトリガーされますvarchar(50)。varchar(128)

メモリ付与の増加に関するマーティンの警告は、非常に有効な懸念事項です。それが実際に問題になる場合は、RAMを追加購入するだけです。

于 2012-07-16T09:23:29.087 に答える
2

こちらをチェックしてください -varchar（max）とvarchar（n）のパフォーマンス比較

于 2012-07-16T08:47:56.577 に答える
0

変更が必要な列のみを変更することをお勧めします。どの列にも50文字を超える文字が必要ない場合は、変更しないでください。

すべての列で長さを同じにすることに関心があるのはなぜですか？すべての列に同じ長さの要件があるとは思えません。

于 2012-07-16T09:44:10.707 に答える
0

そのような列はいくつありますか？ベストプラクティスのルールでは、各列を慎重に計画し、それに応じてサイズを定義する必要があるとされています。すべての列のサイズを盲目的に増やすだけでなく、varchar（128）に適した列を特定する必要があります。

于 2012-07-16T08:08:16.437 に答える