Почему обслуживание индексов SQL Server 2008 выполняется только для индексов с index_level, установленным в 0?

Question

Я использую сценарий дефрагментации индекса от sqlfool.com для сервера SQL, который я изменяю для работы в рамках наших процедур обслуживания в течение ночи. Сценарий - это незавершенная работа, которая изменяется, когда обнаруживаются ошибки или когда могут быть добавлены улучшения. Что мне нравится в этом сценарии, так это то, что его используют многие люди и много думают о нем.

Последнюю версию можно найти здесь http://sqlfool.com/ примерно на полпути вниз по странице.

Есть часть сценария, в которой я не уверен, и пытался отследить некоторую информацию о нем, но, похоже, не могу получить окончательный ответ относительно того, почему это было сделано таким образом.

Ниже приведена часть скрипта, которая используется для определения того, какие индексы следует учитывать при перестройке или реорганизации. Я также включил параметры, которые передаются в процедуру, которая имеет отношение к решению, принятому во вставке.

@minFragmentation       FLOAT               = 10.0  
    /* in percent, will not defrag if fragmentation less than specified */

, @minPageCount           INT                 = 8 
    /*  MS recommends > 1 extent (8 pages) */

, @scanMode               VARCHAR(10)         = N'LIMITED'
    /* Options are LIMITED, SAMPLED, and DETAILED */

INSERT INTO dbo.dba_indexDefragStatus
(
      databaseID
    , databaseName
    , objectID
    , indexID
    , partitionNumber
    , fragmentation
    , page_count
    , range_scan_count
    , scanDate
)
SELECT
      ps.database_id AS 'databaseID'
    , QUOTENAME(DB_NAME(ps.database_id)) AS 'databaseName'
    , ps.[object_id] AS 'objectID'
    , ps.index_id AS 'indexID'
    , ps.partition_number AS 'partitionNumber'
    , SUM(ps.avg_fragmentation_in_percent) AS 'fragmentation'
    , SUM(ps.page_count) AS 'page_count'
    , os.range_scan_count
    , GETDATE() AS 'scanDate'
FROM sys.dm_db_index_physical_stats(@databaseID, OBJECT_ID(@tableName), NULL , NULL, @scanMode) AS ps
JOIN sys.dm_db_index_operational_stats(@databaseID, OBJECT_ID(@tableName), NULL , NULL) AS os
    ON ps.database_id = os.database_id
    AND ps.[object_id] = os.[object_id]
    AND ps.index_id = os.index_id
    AND ps.partition_number = os.partition_number
WHERE avg_fragmentation_in_percent >= @minFragmentation 
    AND ps.index_id > 0 -- ignore heaps
    AND ps.page_count > @minPageCount 
    AND ps.index_level = 0 -- leaf-level nodes only, supports @scanMode
GROUP BY ps.database_id 
    , QUOTENAME(DB_NAME(ps.database_id)) 
    , ps.[object_id]
    , ps.index_id 
    , ps.partition_number 
    , os.range_scan_count
OPTION (MAXDOP 2);

То, что я хотел бы знать, это почему фильтр ниже в там, где предложение?

AND ps.index_level = 0 -- leaf-level nodes only, supports @scanMode

Ниже приведен результат одного из индексов, который показывает, что первый уровень индекса имеет среднюю фрагментацию 99%.

Answer 1

В вашем эталонном изображении index_level 1 и index_level 2 имеют количество страниц менее 1000.

Поскольку на этом уровне индекса очень мало страниц, процент фрагментации не имеет отношения к производительности, это будетповерхностное влияние, чтобы иметь их меньше.

Список литературы:

http://technet.microsoft.com/en-us/library/cc966523.aspx

Как правило, вам не следует беспокоиться об уровнях фрагментации индексов с менее чем 1000 страниц,В тестах индексы, содержащие более 10 000 страниц, показали повышение производительности, при этом наибольший выигрыш был достигнут у индексов со значительно большим количеством страниц (более 50 000 страниц).