0

複合クラスタ化インデックス ( int, DateTime) が 99% 断片化されたテーブルがあります。

最適化を行い、統計が更新されていることを確認した後でも、次のクエリを実行すると、同じ応答時間が得られます。

SELECT *
FROM myTable
WHERE myIntField = 1000 
AND myDateTimeField >= '2012-01-01' 
and myDateTimeField <= '2012-12-31 23:59:59.999'

応答時間はわずかに改善されましたが (5 ～ 10% など)、インデックスの再構築と統計情報の更新後にクエリがバーストすることが予想されていました。

推定実行計画は次のとおりです。

  1. SELECT Cost: 0%
  2. Clustered Index Seek (Clustered)[MyTable].[IX_MyCompoundIndex] Cost: 100%

これは、インデックスがクラスター化インデックスであるためですか? 何か不足していますか？

4

2 に答える 2

1

おそらく、テーブル内のすべての列がSELECT *必要な場合でも(これはまれです)、避ける必要があります。

また、あなたはここで非常に危険なことをしています。最終範囲が切り上げられることをご存知ですか? 2013 年 1 月 1 日午前 0 時のデータが含まれている可能性があります。試す：

AND myDateTimeColumn >= '20120101' 
AND myDateTimeColumn <  '20130101'

(これによってパフォーマンスが変わることはありませんが、生成が簡単になり、基になるデータ型が何であれ正確であることが保証されます。)

クエリ時間の分析からネットワーク遅延を排除するには、SQL Sentry Plan Explorerを検討できます。これにより、サーバーに対してクエリを実行して実際のプランを生成できますが、結果は破棄されるため、干渉要因にはなりません。

免責事項: 私は SQL Sentry で働いています。

于 2012-09-24T14:48:17.537 に答える
0

クエリの実行時間は、結果を生成するためにインデックスの btree の十分なページを読み取るために費やされます。インデックスを最適化すると、隣接する行がまとめられ、読み取る必要のあるページ数が減ります。また、大部分がランダムな io パターンをシーケンシャルな io パターンに変換することからも恩恵を受けることができます。

行の幅が広く、1 ページあたりの行数が少ない場合、行数が大幅に減少することはありません。

インデックスの FILL FACTOR が低いと、ページあたりの行数が少なくなります。

ページがキャッシュにある場合、ストリーミングとランダム IO の利点は見られません。

マシンの CPU 容量に余裕がある場合は、ページ圧縮を使用すると効果が得られる場合があります。これは基本的に、より少ない IO でより多くの CPU をトレードします。

于 2012-09-24T15:07:59.697 に答える