断片化を放置すると遅くなる？SQL Serverのインデックス再構築と再編成の違いを徹底解説
SQL Serverの性能を維持するうえで欠かせないのがインデックスのメンテナンスです。
データの更新・削除・挿入を繰り返すうちに、インデックスページの物理的な順序が崩れ、
検索性能が低下する「断片化」が発生します。
この記事では、再構築（REBUILD）と再編成（REORGANIZE）の違い、実行タイミング、
ALTER INDEXの構文を中心に、実務で使えるメンテナンス手法を解説します。
目次
インデックス断片化とは？
ページ分割と空き領域の増加が原因
インデックスはBツリー構造で管理されていますが、 データの更新や削除によって物理ページの順序が乱れ、無駄なI/Oが発生します。 これが断片化（Fragmentation）です。
断片化が進むと次のような影響が出ます：
- SELECTクエリの読み取りI/Oが増加
- キャッシュ効率が低下し、バッファプールを圧迫
- 統計情報の精度低下による最適化のミス
断片化の確認方法
DMF（動的管理関数）で確認する
SELECT
dbschemas.[name] AS SchemaName,
dbtables.[name] AS TableName,
dbindexes.[name] AS IndexName,
indexstats.avg_fragmentation_in_percent,
indexstats.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') AS indexstats
INNER JOIN sys.tables dbtables ON dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas ON dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
WHERE indexstats.database_id = DB_ID()
ORDER BY indexstats.avg_fragmentation_in_percent DESC;
avg_fragmentation_in_percentが高いほど断片化が進行しています。
ALTER INDEXによるメンテナンスの種類
インデックス操作の基本構文
ALTER INDEX インデックス名 ON テーブル名
REBUILD; -- 再構築
ALTER INDEX インデックス名 ON テーブル名
REORGANIZE; -- 再編成
また、全インデックスに対して一括実行も可能です：
ALTER INDEX ALL ON テーブル名 REBUILD;
ALTER INDEX ALL ON テーブル名 REORGANIZE;
次に、それぞれの違いを見ていきましょう。
インデックス再編成（REORGANIZE）の特徴
オンラインで軽量なメンテナンス
- ページを物理的に並べ替える
- 軽量処理のためトランザクションログへの影響が小さい
- ONLINE実行が可能（ロック影響が少ない）
断片化が軽度（10〜30％程度）の場合に適しています。
実行例
ALTER INDEX IX_Sales_CustomerID ON Sales REORGANIZE;
また、再編成時にページの空き領域（FILLFACTOR）を変更することも可能です。
インデックス再構築（REBUILD）の特徴
インデックスを完全に作り直す
- 古いインデックスを削除して新規に再作成
- 断片化を100％除去
- 統計情報も自動的に更新される
その反面、リソース消費が大きく、ログ量も増加します。 断片化が重度（30％以上）の場合に適しています。
実行例
ALTER INDEX IX_Sales_CustomerID ON Sales REBUILD WITH (ONLINE = ON, FILLFACTOR = 90);
ONLINE = ONを指定すると、DML操作と並行して再構築が可能（Enterprise Edition以上）。
再構築と再編成の判断基準
断片化率による目安
| 断片化率 | 推奨操作 |
|---|---|
| 0〜10％未満 | 処理不要 |
| 10〜30％ | REORGANIZE（再編成） |
| 30％以上 | REBUILD（再構築） |
この閾値はMicrosoft公式ドキュメントでも推奨されています。
自動化と実務での運用ポイント
① 定期メンテナンスジョブを設定
SQL Server Agentを利用し、夜間など負荷の少ない時間に自動実行します。
EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE',
@FragmentationHigh = 'INDEX_REBUILD',
@UpdateStatistics = 'ALL';
上記は定番ツール「Ola Hallengren’s Maintenance Solution」の設定例です。
② 統計更新のタイミングを意識
REBUILD時は統計が自動更新されますが、REORGANIZEでは更新されません。
必要に応じて UPDATE STATISTICS を併用します。
③ トランザクションログ容量に注意
再構築では大量ログが出るため、ログバックアップの実行間隔やドライブ容量を事前に確認しておきましょう。
まとめと次のステップ
学んだ内容の整理
- 断片化はインデックスの物理順序が乱れる現象。
- REORGANIZEは軽量・オンライン処理向き、REBUILDは完全再構築。
- 断片化率10〜30％で再編成、30％以上で再構築が目安。
- 統計更新やログ管理も合わせて実施するのが実務のコツ。
参考リンク
0 件のコメント:
コメントを投稿