最近、少しブログをサボり気味でした。また再開したいと思います。よろしくお願いします(^o^)/ SQL Server のチューニングについてまとめてみる - その1 - ( インデックスの調査 ) - 都内で働くSEの技術的なひとりごと に関する補足です。
まずは、自分のデータベースに対していろいろなクエリを投げている状態で、そのクエリに対するインデックスがどのくらい不足しているかをざっくり参照する方法から試してみましょう。sys.dm_db_missing_index_details から取得できます。以下のクエリを SQL Server Management Studio で発行してみましょう。( 単純にカウントするだけです... )
SELECT DB_NAME(database_id) as [データベース名],
count(*) as [期待しているインデックスが存在しない数]
FROM sys.dm_db_missing_index_details
GROUP BY DB_NAME(database_id)
出力される数によっては、悲しい現実が待っています。インデックスが作成されていないため、DBMS に多大な負荷を与えている現状が把握できてしまいます。これだけでは、何をしていいかわかりませんので、SQL Server のチューニングについてまとめてみる - その1 - ( インデックスの調査 ) - 都内で働くSEの技術的なひとりごと で使用した調査クエリに avg_user_impact を追加します。これは、インデックスを作成した場合のパフォーマンス改善率です。
USE AdventureWorks2012
SELECT gs.avg_user_impact AS [予測されるクエリパフォーマンス改善率],
gs.last_user_seek AS [最後にシークした時間],
id.statement AS [テーブル名] ,
id.equality_columns AS [等値述語に使用できる列],
id.inequality_columns AS [不等値述語に使用できる列] ,
id.included_columns AS [包括列として必要な列],
gs.unique_compiles AS [コンパイルおよび再コンパイルの数],
gs.user_seeks AS [クエリによって発生したシーク数]
FROM sys.dm_db_missing_index_group_stats AS gs
INNER JOIN sys.dm_db_missing_index_groups AS ig
ON gs.group_handle = ig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details AS id
ON ig.index_handle = id.index_handle
WHERE id.[database_id] =DB_ID() Order By gs.last_user_seek ASC
83.09 % 改善できるという結果になりました。インデックスは作成する必要があるかと思うのですが、テーブル更新時のパフォーマンス劣化、容量増大の要因にもなりますので、慎重に考える必要があります。( 包括列は特に慎重に.... )
この列を加えることによって、どのインデックスを優先的に作成するかの指標になるかと思います。頑張ってクエリパフォーマンスを向上させましょう。( 前回の記事でちゃんと付け加えていれば、補足はいらなかったのですが..... )