8

「単純な選択クエリの応答時間を短縮するにはどうすればよいですか?」という質問へのコメント 教えて：

  • 「LaunchDate のデータ型は何ですか? DATETIME または DATETIME2 の場合、時間部分が含まれているため、インデックスはあまり機能しない可能性があります – OMG Ponies」

  • 「@OMG - DateTime 列のクラスター化インデックスがパフォーマンスを向上させないのはなぜですか?クエリは範囲スキャンであり、すべてのデータが順次ブロックにあるため、高速範囲インデックス検索が可能になりますか?準関連... msdn. microsoft.com/en-us/library/ms177416.aspx – カルガリー コーダー"

  • 「カルガリー コーダー: DATETIME/2 には時間が含まれます。クラスター化または非クラスター化されたインデックスは、時間は重複するが範囲ではない日付に適しています。 – OMG Ponies」

DATETIMEタイプ列にクラスター化インデックスを使用してテスト テーブルを作成しLaunchDate、上記の質問で引用したようなクエリのインデックス シークを観察しました。

SELECT COUNT(primaryKeyColumn) 
FROM   MarketPlan 
WHERE  LaunchDate > @date

テーブルまたはインデックスのスキャンの代わりに。

列のクラスター化インデックスがDateTimeパフォーマンスを向上させないのはなぜですか? 時間部分が含まれている場合、または時間が含まれているため、
インデックスがあまり機能しないのはなぜですか?DATETIMEDATETIME2

DATETIME列のインデックスを作成してもパフォーマンスが向上しないこと を示すスクリプトをいただければ幸いです。

更新: また、OMG はDATEtype 列のインデックスが役立つことを暗示していましたが、そうではDATETIMEありませんでしたDATETIME2か?

4

2 に答える 2

4

他の質問を読みましたが、OMG ポニーの意味がわかりません

3点：

  • インデックスがクラスター化されているかどうかは問題ではありません。
  • 時間も含めて構いません
  • それはただ有用でなければなりません

シークまたはスキャン:

統計に基づいてLaunchDate > @date、たとえば行の 90% を意味する場合、スキャンが行われる可能性が最も高くなります。かなり選択的である場合は、シークの可能性が高くなります。

クラスター、非クラスター問わず！

何の指標？

このようなクエリには、LaunchDate と primaryKeyColumn のインデックスが必要です。

SELECT COUNT(primaryKeyColumn) 
FROM   MarketPlan 
WHERE  LaunchDate > @date

現在、非クラスター化インデックスは、既定で PK と見なされるクラスター化インデックスを参照します。したがって、primaryKeyColumn は既に暗黙的に含まれています。

迷信

しかし、COUNT(primaryKeyColumn) 迷信です。PK は NULL を許可しないため、

SELECT COUNT(*) 
FROM   MarketPlan 
WHERE  LaunchDate > @date

SELECT COUNT(1) 
FROM   MarketPlan 
WHERE  LaunchDate > @date

したがって、クラスター化されているかどうかに関係なく、LaunchDate のインデックスのみが必要です。

于 2010-11-20T12:12:19.850 に答える
0

アプリケーションが暗黙的なデータ型変換を引き起こす datetime を使用する場合、日付列のインデックスは使用されません。実行計画を見ると、列に内部関数が適用されていることがわかります。解決策は、日付列をタイムスタンプ (4) に変更するか、クライアント アプリケーションを調整して、日時の代わりに日付を使用することです。

于 2014-03-05T08:32:09.603 に答える