都内で働くSEの技術的なひとりごと

都内でサラリーマンやってます。マイクロソフト系(たまに、OSS系などマイクロソフト以外の技術も...)の技術的なことについて書いています。日々の仕事の中で、気になったことを技術要素関係なく気まぐれに選んでいるので記事内容は開発言語、インフラ等ばらばらです。なお、当ブログで発信、発言は私個人のものであり、所属する組織、企業、団体等とは何のかかわりもございません。ブログの内容もきちんと検証して使用してください。よろしくお願いします♪

SQL Server のチューニングについてまとめてみる - その3 - ( パフォーマンスがどれくらい改善される? )

 最近、少しブログをサボり気味でした。また再開したいと思います。よろしくお願いします(^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)

f:id:koogucc11:20140525090601p:plain

出力される数によっては、悲しい現実が待っています。インデックスが作成されていないため、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

f:id:koogucc11:20140525092400p:plain

 83.09 % 改善できるという結果になりました。インデックスは作成する必要があるかと思うのですが、テーブル更新時のパフォーマンス劣化、容量増大の要因にもなりますので、慎重に考える必要があります。( 包括列は特に慎重に.... )

 この列を加えることによって、どのインデックスを優先的に作成するかの指標になるかと思います。頑張ってクエリパフォーマンスを向上させましょう。( 前回の記事でちゃんと付け加えていれば、補足はいらなかったのですが..... )