最近、インデックスを追加していくつかのクエリを調整し、そのテーブルの全体的な状況が改善されたかどうかを評価しようとしています。
からいくつかのメトリックを取得しまし sys.dm_db_index_usage_statsた。最初のグラフは、その特定の新しいインデックスの全体 user_seeks(スキャン、ルックアップ、および user_updates (書き込み))の数の違いを示しています。2番目のグラフは、そのインデックスのすべての読み取りから単純に減算します。 user_updatesこれらの数字だけを見ると、インデックスが実際に読み取るよりも書き込まれていることがはっきりとわかります。
ただし、このインデックスは特に、24 時間年中無休で毎分サーバーにヒットする 2 つの監視クエリに役立ちました。このインデックスを追加する前に、これらのクエリはクラスター化インデックス スキャンを実行しました。クラスター化インデックスのメトリックを見ると、新しいインデックスがシークされるのと同じ割合 (6 時間ウィンドウあたり 720 回のシーク、したがって 1 日あたり 2.880 回のシーク (または以前のクラスター化インデックス スキャン)) でスキャン数が減少したことが明確にわかります。
辛抱強く、これをすべて読んでくれてありがとう....今私の質問に。新しいインデックスへの MB 書き込みのボリュームをどのように計算できますか? すべてのテーブル スキャンによる IO (MB 単位) と、その後の新しいインデックスの検索と維持による IO を比較したいと思います。
それが私が行った計算です：
Read IO Table Scan 79.977 Reads / 128 = 765,45 MB
-Read IO Index Seek 15 Reads / 128 = 0,12 MB
= Read IO Savings per query 765,33 MB
Read IO savings per day 765,33 MB * 2.880 = 2.152 GB
- 1 日あたりの新しいインデックスの書き込み 26.000 回の書き込み * 書き込まれる行あたり 49 バイト = 1.274.000 バイト
Overall benefit per day 2.152 - 754.000/(1024^3) = 2.152 - 0,0011= 2.151,99 ?????
クエリのチューニング中にこの情報を収集したため、読み取り IO の節約は非常に簡単です。ただし、そのインデックスに書き込むための IO オーバーヘッドをどのように計算 (または知識に基づいた推測) できますか? 1 日あたり約 26,000 回の書き込みを行っていることがわかっています。インデックスの構造は次のとおりです。
[2 つのキー] column1 {datetime 8}、column2 {datetime 8} [3 INCLUDES] column3 {ビット 1}、column4 {bigint 8}、column5 {int 4} [秘密の列 (クラスター化されたキー)] [3 つのキー] column6 { bigint 8}、column7 {bigint 8}、column8{int 4}
したがって、リーフ レベルのレコードには 49 バイトがあると思います (すべての数値を合計します)。ありますか？どうすれば中間レベルを推測できますか?
とにかく...（「教育を受けた推測」の方向性について）あなたの経験では、とにかくテーブルをスキャンして通常の方法でこれを行うことから私を救っているので、それは本当に重要ですか？
クエリ チューニングの利益計算に関する洞察を読んで共有していただき、ありがとうございます。
