すべてを再構築してインデックスを再作成した後、データベースがまだ断片化されているのはなぜですか？

このT-SQLを実行して、すべてのテーブルを一度に最適化しようとしたデータベースがあります。

SELECT 
        'ALTER INDEX all ON ' + name + ' REORGANIZE;' + CHAR(10) +
        'ALTER INDEX all ON ' + name + ' REBUILD;'
    FROM sys.tables

次に、出力を新しいクエリウィンドウにコピーアンドペーストして実行します。エラーは発生しませんでしたが、まだ断片化しています。私も両方のコマンドを別々に実行しようとしましたが、まだ断片化しています。注：REORGANIZEアーロンはこれが不要であることを認識しており、動的SQLを使用してこれを自動化できることを認識しています。

私はこれを実行して、まだ断片化があることを確認しました：

SELECT * FROM 
sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, NULL) 
WHERE avg_fragmentation_in_percent > 0

そして私は得た：

database_id object_id   index_id    partition_number    index_type_desc alloc_unit_type_desc    index_depth index_level avg_fragmentation_in_percent    fragment_count  avg_fragment_size_in_pages  page_count  avg_page_space_used_in_percent  record_count    ghost_record_count  version_ghost_record_count  min_record_size_in_bytes    max_record_size_in_bytes    avg_record_size_in_bytes    forwarded_record_count  compressed_page_count
85  171147655   1   1   CLUSTERED INDEX IN_ROW_DATA 2   0   36.3636363636364    5   2.2 11  NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL
85  421576540   1   1   CLUSTERED INDEX IN_ROW_DATA 2   0   75  7   1.14285714285714    8   NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL
85  965578478   1   1   CLUSTERED INDEX IN_ROW_DATA 2   0   14.7058823529412    6   5.66666666666667    34  NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL
85  1061578820  1   1   CLUSTERED INDEX IN_ROW_DATA 2   0   40  4   1.25    5   NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL
85  1109578991  1   1   CLUSTERED INDEX IN_ROW_DATA 2   0   30.7692307692308    5   2.6 13  NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL
85  1205579333  2   1   NONCLUSTERED INDEX  IN_ROW_DATA 2   0   50  5   1.6 8   NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL
85  1493580359  1   1   CLUSTERED INDEX IN_ROW_DATA 2   0   50  6   1.66666666666667    10  NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL    NULL

本当に基本的なものが欠けていることは知っていますが、何がわからないのですか。

テーブルは小さいです。テーブル内のページ数は次のとおりです。

11、8、6、5、13、8、10

合計で480kbを占有します。文字通りデフラグするものはまったくありません。

編集：これはもう少し説明を保証します。

通常、新しいテーブルまたはインデックスは、均一なエクステントではなく、混合エクステントからの最初の8ページに割り当てられます。そのため、最初の8ページのそれぞれを異なる混合エクステントから割り当てることができます。したがって、8ページを消費するテーブルまたはインデックスは、8つの異なる混合エクステントのそれぞれに1つずつ、8つのフラグメントを持つことができます。

より広く使用されているデフラグスクリプト（以下にリンクされているいくつかの例）は、このため小さなテーブルを除外する傾向があります。IIRC、<500ページはそれらの一方または両方にあります。これらのサイズでは、デフラグの利点はほとんどなく、混合エクステントの割り当てによって断片化の数値が歪む可能性があります。

• Ola Hallengren-SQL Serverメンテナンスソリューション
• SQL Fool-インデックスデフラグスクリプト

「Microsoft SQL Server 2000インデックスデフラグベストプラクティス」からの引用：

「断片化はディスクI / Oに影響します。したがって、ページがSQL Serverによってキャッシュされる可能性が低いため、より大きなインデックスに注目してください。DBCCSHOWCONTIGによって報告されるページ数を使用して、サイズは8 KB）。一般的に、あなたは以下の1,000ページとインデックスの断片化レベルに関係するべきではありません。テストでは、かなり多くのページ（大きいとインデックスの最大の利益で、パフォーマンスの向上を実現10,000人以上のページを含むインデックス50,000ページ以上）。」

したがって、この種の質問はあなたの質問に答え、マークとアーロンの答えを支持します。

インデックスの断片化に関する適切な情報は、Brent Ozarの次の記事にあります。

• インデックスフラグメンテーションの調査結果：パート1、基本
• インデックスの断片化の調査結果：パート2、サイズの問題

また、一般的なインデックス（およびフラグメンテーションの問題）に関するすばらしい情報が、Kimberly Trippのブログにあります。

これは質問に答えるためのものではありませんが、コメントに収まることはありません。出力をコピーして別のウィンドウに貼り付けることなく、このスクリプトを動的に構築できます。理由は絶対にありませんことを考慮するREORGANIZEと、その後REBUILD：

DECLARE @sql NVARCHAR(MAX) = N'';

SELECT @sql += N'ALTER INDEX all ON ' + name + ' REBUILD;
    ' FROM sys.tables;

PRINT @sql; -- to see the first 8,000 characters and make sure it checks out
-- EXEC sp_executesql @sql;