最近インデックスを追加してクエリをチューニングしましたが、そのテーブルの全体的な状況が良くなったかどうかを確認しようとしています。SQL Server：クエリのパフォーマンス利益の計算
sys.dm_db_index_usage_statsからいくつかの指標を取得しました。 の最初のチャートは、と、その特定の新しいインデックスの全体の数であるuser_seeks（スキャン、ルックアップとユーザー更新（書き込み））の違いを示しています。 第2のチャートは単にで、そのインデックスのすべての読み取り値からuser_updatesを減算します。これらの数字だけを見ると、インデックスは実際に読んだものより多く書かれていることがはっきりと分かります。
ただし、このインデックスは、特に24時間365日にサーバーに当たる2つの監視クエリに役立ちました。このインデックスを追加する前に、それらのクエリはクラスタ化インデックススキャンを行いました。クラスタード・インデックスのメトリックを見ると、新しいインデックスが同じレートで削除されたことがわかります（6時間のウィンドウあたり720シーク、したがって2.880シーク（または以前のクラスタード・インデックス・スキャン））。
私は新しいインデックスにMB書き込みの量をどのように計算できるのですか？ 。
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
だから、私がやった計算です
- 日あたりの新しいインデックスに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 KEYS] column1 {datetime 8}, column2 {datetime 8} [3 INCLUDES] column3 {bit 1}, column4 {bigint 8}, column5 {int 4} [SECRET COLUMNS (Clustered Key)] [3 KEYS] column6 {bigint 8}, column7 {bigint 8}, column8{int 4}
だから、葉レベルのレコードには49バイト（すべての数字を集計）が含まれていると思います。それはありますか？どのように中間レベルを推測することができますか？
あなたの経験の中で（もっと教育的な推測の方向に）...それは本当に重要なのですが、私はいつもテーブルをスキャンして、これを通常のやり方でやっていますか？
私はクエリのチューニングの利益の計算を読んでいただきありがとうございます。
