SQL Serverを運用していると、これまで問題なく動作していたクエリが急に遅くなる、バッチ処理の完了時間が延びるといった事象に直面することがあります。
こうしたパフォーマンス低下は、アプリケーション側の変更だけでなく、データ量の増加や内部構造の劣化が原因となるケースも少なくありません。
本記事では、特に効果が出やすい「インデックスの再構築」と「統計情報の更新」を中心に、運用中のシステムですぐ実践できる基本操作を解説します。
インデックスの断片化が引き起こす処理遅延
この章では、SQL Serverにおけるインデックス断片化の仕組みと、なぜパフォーマンス低下につながるのかを整理します。
断片化の本質を理解することで、適切なメンテナンスタイミングを判断しやすくなります。
インデックス断片化とは何か
インデックスは、テーブル内のデータを効率よく検索するための構造です。
しかし、INSERT・UPDATE・DELETE を繰り返すことで、データページの物理的な並びが崩れ、連続性が失われます。この状態をインデックスの断片化と呼びます。
断片化が進行すると、次のような影響が現れやすくなります。
- 不要なディスク I/O が増加する
- バッファキャッシュの効率が低下する
- 大量データを扱うクエリほど処理時間が伸びる
特に、テーブルサイズが大きい環境では、断片化の影響が顕著に表れます。
断片化が起きやすい運用パターン
運用現場でよく見られる断片化しやすいケースは以下のとおりです。
- 日次・月次で大量データが追加される履歴・ログ系テーブル
- ステータス更新が頻繁に行われる業務テーブル
- 主キー以外の非クラスター化インデックスが多い設計
これらは避けがたい構成であるため、断片化を前提とした定期メンテナンスが重要になります。
インデックス再構築（REBUILD）の役割と注意点
ここでは、断片化対策の中核となるインデックス再構築について解説します。
効果が高い一方で、実行時の影響も理解しておく必要があります。
インデックス再構築の基本的な役割
インデックス再構築（REBUILD）は、既存インデックスを一度作り直す処理です。
断片化されたページが再配置され、論理・物理両面で最適化されます。
SQL Serverの例
ALTER INDEXALLON WK_DFW_AMY0J_U5006 REBUILD;
この操作により、インデックスの構造が整理され、検索性能やスキャン効率の改善が期待できます。
運用時に注意すべきポイント
実行にあたっては、次の点を必ず意識してください。
- テーブルに排他ロックがかかるため、業務時間帯の実行は避ける
- 大規模テーブルでは CPU・I/O 負荷が一時的に増大する
- Enterprise Edition では
ONLINE = ONによりオンライン再構築が可能
Standard Edition を利用している場合は、夜間バッチなど影響の少ない時間帯に実行するのが基本です。
インデックス REBUILD と REORGANIZE の使い分け
この章では、よく混同されがちな REBUILD と REORGANIZE の違いを整理します。
断片化率に応じた使い分けが、安定運用の鍵になります。
REORGANIZE の特徴
REORGANIZE は、インデックスを部分的に整理する軽量な処理です。
- ロックが短時間で済み、オンライン実行が可能
- 負荷は低いが、断片化解消の効果は限定的
- 統計情報は更新されない
使い分けの目安
一般的な判断基準として、次のルールがよく使われます。
- 断片化率 5～30% → REORGANIZE
- 断片化率 30%以上 → REBUILD
この基準を採用することで、無駄な負荷を抑えつつ効率的なメンテナンスが可能になります。
統計情報の更新（UPDATE STATISTICS）でクエリプランを最適化
この章では、インデックスと並んで重要な統計情報の役割を解説します。
統計情報の鮮度は、クエリ性能に直結します。
統計情報がクエリに与える影響
SQL Server は、統計情報をもとに実行計画を生成します。
データ分布の変化に統計情報が追従していない場合、以下のような問題が発生します。
- 想定行数と実際の行数が大きく乖離する
- 不適切なインデックスが選択される
- 結果として処理時間が増加する
データ増減が激しいテーブルでは、特に注意が必要です。
統計情報を明示的に更新する方法
SQL Serverの例
UPDATE STATISTICS WK_DFW_AMY0J_U5006WITH FULLSCAN,ALL;
WITH FULLSCANにより高精度な統計情報を取得できる- 実行時間は長くなるため、定期バッチでの実行が現実的
自動更新任せでは不十分なケースも多く、手動更新は重要な運用テクニックです。
インデックス断片化率を確認するクエリ
この章では、メンテナンス判断の根拠となる断片化率の確認方法を紹介します。
実行前に必ず確認する習慣をつけると安全です。
断片化率確認用クエリ
SQL Serverの例
SELECT
OBJECT_NAME(ps.object_id)AS TableName,
i.nameAS IndexName,
ps.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats
(DB_ID(),NULL,NULL,NULL,'SAMPLED') ps
INNERJOIN sys.indexes i
ON ps.object_id= i.object_id
AND ps.index_id= i.index_id
WHERE ps.index_id>0
ORDERBY ps.avg_fragmentation_in_percentDESC;
この結果をもとに、REORGANIZE か REBUILD かを判断すると、無駄な処理を避けられます。
【サンプル】定期実行スクリプトの例
ここでは、実運用で使いやすいメンテナンススクリプト例を紹介します。
インデックスと統計情報をまとめて管理できます。
定期メンテナンス用SQLスクリプト
ALTER INDEXALLON WK_DFW_AMY0J_U5006 REBUILD;
UPDATE STATISTICS WK_DFW_AMY0J_U5006WITH FULLSCAN,ALL;
ALTER INDEXALLON MPOMST REBUILD;
UPDATE STATISTICS MPOMSTWITH FULLSCAN,ALL;
SQL Server Agent に登録しておくことで、人的ミスを防ぎながら安定運用が可能になります。
インデックス再構築と統計更新のメリット・デメリット
この章では、両者の特徴を整理します。
状況に応じた使い分けの参考にしてください。
主な比較ポイント
| 項目 | メリット | デメリット |
|---|---|---|
| インデックス再構築 | 断片化解消、検索性能向上 | ロック・高負荷 |
| 統計情報更新 | 実行計画の最適化 | 実行時間・リソース消費 |
まとめ：パフォーマンス低下時の“基本”を押さえる
SQL Serverの処理が遅くなった場合、まず確認すべきはインデックス断片化と統計情報の鮮度です。
以下を定期的に実施することで、多くの性能問題は予防できます。
- 断片化率を確認して REBUILD / REORGANIZE を使い分ける
- 統計情報を定期的に明示更新する
これらをジョブ化・自動化することで、安定したパフォーマンスと運用負荷軽減を両立できます。
日常運用の基本として、ぜひ取り入れてみてください。
コメント