7

重複の可能性:
varchar(8000) よりも varchar(500) に利点はありますか?

10 文字を含む列は、同じデータを含む列VARCHAR(200)と同じ量のスペースを必要とすることを理解しています。VARCHAR(20)

VARCHAR(200)特定のテーブルの多数の列を変更するVARCHAR(20)と、特に次の場合にクエリが高速になるかどうかを知りたいです。

  • これらの列に 20 文字を超えることはありません
  • これらの列はORDER BY節でよく使用されます
  • これらの列はWHERE節 でよく使用されます
    • これらの列の一部は、WHERE句で使用できるように索引が付けられています

PS: SQL Server 2000 を使用していますが、近いうちに新しいバージョンの SQL にアップグレードする予定です。

4

4 に答える 4

13

はい、varchar の長さは、クエリの見積もり、内部操作 (並べ替えなど) に割り当てられるメモリ、および結果として CPU のリソースに影響します。次の簡単な例で再現できます。

1.2 つのテーブルを作成します。

create table varLenTest1
(
    a varchar(100)
)

create table varLenTest2
(
    a varchar(8000)
)

2. 両方にデータを入力します。

declare @i int
set @i = 20000

while (@i > 0)
begin 
    insert into varLenTest1 (a) values (cast(NEWID() as varchar(36)))
    set @i = @i - 1
end

3. 「実際の実行計画を含める」を使用して次のクエリを実行します。

select a from varLenTest1 order by a OPTION (MAXDOP 1) ;
select a from varLenTest2 order by a OPTION (MAXDOP 1) ;

これらのクエリの実行プランを調べると、推定 IO コストと推定 CPU コストが大きく異なることがわかります。 ここに画像の説明を入力

于 2012-12-15T20:44:48.767 に答える
2

クエリオプティマイザーがクエリを実行するのに最適なクエリパスをいつ評価するかは重要です。複数のパスが使用可能な場合、クエリに基づいてI / Oコストやその他のさまざまなパラメータが計算され、これらから、最もコストが低いと思われるパスが選択されます。

これは絶対的な計算ではなく、単なる概算プロセスです。したがって、メモリ内の1つのテーブルのレコードを操作するために必要な見かけの平均サイズが実際に必要なものよりもはるかに大きい場合、オプティマイザーは必要と思われるものに基づいてパフォーマンスの低いパスを選択する可能性があります。他のパスのために。

現実的な最大サイズを持つことは、コードを見に来る他のプログラマーにとっても役立ちます。GUIに表示したい変数がある場合、サイズがそれより大きくなることはありません。

于 2012-12-15T18:11:25.673 に答える
2

以下は、異なる列サイズを使用した場合にパフォーマンスの違いが発生する状況と理由を説明するブログ投稿です (テストと技術的な詳細を含む)。

高度な TSQL チューニング: 内部の知識が重要な理由

于 2012-12-15T17:45:39.570 に答える
1

サイズが重要

可能な限り最大の値に対応できる最小のデータ サイズを常に使用してください。列に 1 ～ 5 の値を格納する場合は、int の代わりに tinyint を使用します。

この規則は文字列にも適用されます。データ サイズが小さければ小さいほど、読み取りが少なくなるため、全体的にパフォーマンスが向上します。さらに、サイズが小さくなると、ネットワーク トラフィックが減少します。新しいテクノロジーでは、このヒントはあまり意味がないように見えますが、すぐに無視しないでください。最初から効率的であることを後悔することはありません。

詳細については、http://www.techrepublic.com/blog/10-things/10-plus-tips-for-getting-the-best-performance-out-of-your-sql-server-data-types/ をご覧ください。

于 2012-12-15T17:46:44.410 に答える