はじめに
SQL Serverでパフォーマンスを意識し始めると、「インデックスの断片化」という言葉をよく見かけます。
ただ、「断片化ってどうやって確認するの？」と疑問に思ったことはないでしょうか。
本記事では、SQL Serverでインデックスの断片化を確認する方法を、実務でよく使う形に絞ってわかりやすく解説します。
なお、SQL Serverではクラスタ化インデックスがテーブルの実体となるため、断片化もインデックス単位で発生します。
このあたりの仕組みについては、SQL Serverにテーブル再編成（REORG）がない理由を解説した以下の記事で詳しく説明しています。
SQL Serverにテーブル再編成（REORG）がない理由｜Db2・Oracleとの違いも解説
結論：DMVを使えば一発で確認できる
インデックスの断片化は、DMV（動的管理ビュー）を使うことで簡単に確認できます。
以下のクエリを実行するだけです。
SELECT
DB_NAME(database_id) AS database_name,
OBJECT_NAME(object_id) AS table_name,
index_id,
avg_fragmentation_in_percent
FROM
sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED')
WHERE
index_id > 0
ORDER BY
avg_fragmentation_in_percent DESC;
結果の見方（ここが重要）
この結果で見るべきポイントは「avg_fragmentation_in_percent」です。
断片化の目安は以下の通りです。
・5%未満 → 問題なし
・5〜30% → REORGANIZE検討
・30%以上 → REBUILD検討
この基準をもとに、メンテナンスの判断を行います。
もう少しだけ解説
このクエリで使っている「sys.dm_db_index_physical_stats」は、インデックスの物理的な状態を確認できるDMVです。
取得モードにはいくつか種類がありますが、通常は「LIMITED」で十分です。
・LIMITED → 軽量（通常はこれ）
・SAMPLED → 中程度
・DETAILED → 高負荷
本番環境では負荷を考慮して使い分けることが重要です。
より詳しい仕様や各パラメータについては、Microsoftの公式ドキュメントが参考になります。
sys.dm_db_index_physical_stats の詳細は以下をご参照ください。
※詳細な仕様や注意点は公式ドキュメントもあわせて確認するのがおすすめです。
実務での使い方
実務では、単発で確認するだけでなく、定期的に断片化をチェックしてメンテナンスにつなげます。
例えば、
・定期的に断片化を確認
・閾値を超えたらREORGANIZE / REBUILD
といった運用にすることで、パフォーマンス低下を防ぐことができます。
インデックスの再構成・再構築については、以下の記事で詳しく解説しています。
SQL ServerのREORGANIZEとREBUILDの違い｜使い分けと判断基準を解説
よくある注意点
・ヒープテーブルは対象外（index_id = 0）
・全件取得すると重くなる
・本番環境では負荷に注意
特にDETAILEDモードは負荷が高いため、むやみに使わないようにします。
まとめ
SQL Serverでインデックスの断片化を確認するには、DMVを使うのが最も簡単です。
・avg_fragmentation_in_percentを見る
・5〜30% → REORGANIZE
・30%以上 → REBUILD
この流れを押さえておけば、基本的な運用は問題ありません。
なお、インデックスが使われない場合の原因については、以下の記事で解説しています。
コメント