Почему происходит сканирование моего кластерного индекса?

Question

SQL 2000
Таблица NED имеет внешний ключ для таблицы SIGN. NED.RowID для SIGN.RowID
Таблица SIGN имеет внешний ключ для таблицы NED SIGN.SignID для NED.SignID
RowID и SignID являются кластерными первичными ключами, которые являются GUID (не мой выбор)
Предложение WHERE:

FROM
    [SIGN] A   
    INNER JOIN NED N ON A.SIGNID = N.SIGNID  
    INNER JOIN Wizard S ON A.WizardID = S.WizardID   
    INNER JOIN [Level] SL ON N.LevelID = SL.LevelID  
    LEFT JOIN Driver DSL ON SL.LevelID = DSL.LevelID  
        AND DSL.fsDeptID = @fsDeptID  
    INNER JOIN [Character] ET ON S.CharacterID = ET.CharacterID  
    INNER JOIN Town DS ON A.TownID = DS.TownID   
WHERE  
    (A.DeptID = @DeptID OR   
    S.DeptID = @DeptID  
    AND   
    A.[EndTime] > @StartDateTime AND A.[StartTime] < @EndDateTime  
    AND   
    A.NEDStatusID = 2    

Почему в таблице SIGN для этого запроса есть INDEX SCAN? Что может вызвать сканирование индекса кластерного индекса? Спасибо

Answer 1

Сканирование кластеризованного индекса - это то, как SQL Server назначает полное сканирование таблицы для таблицы с кластеризованным индексом. Это связано с тем, что у вас недостаточно индексов в таблице SIGN, чтобы удовлетворить предложению WHERE, или потому, что было решено, что таблица SIGN достаточно мала (или индексы недостаточно избирательны), чтобы сканирование таблицы было более эффективным.

Просто, изучив запрос, вам, вероятно, придется проиндексировать столбец DeptID, а также некоторую комбинацию StartTime, EndTime и NEDStatusID, чтобы избежать сканирования таблицы. Если причина, по которой вы спрашиваете, заключается в том, что у вас проблемы с производительностью, вы также можете запустить мастер настройки индекса (теперь помощник по настройке ядра СУБД в клиентских инструментах SQL2005 +) и дать ему несколько советов о том, какие индексы создавать для ускорения. на ваш запрос.

Answer 2

Поскольку ваше предложение WHERE не относится к индексированным столбцам.

Answer 3

Вот хороший пост в блоге о том, когда SQL Server достигает «переломного момента» и переключается с поиска индекса на сканирование индекса / таблицы:

http://www.sqlskills.com/BLOGS/KIMBERLY/post/The-Tipping-Point-Query-Answers.aspx

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

Answer 4

У вас есть несколько ограничений на таблицу SIGN A, если я правильно прочитал:

WHERE  
        (A.DeptID = @DeptID OR   
        S.DeptID = @DeptID  
        AND   
        A.[EndTime] > @StartDateTime AND A.[StartTime] < @EndDateTime  
        AND   
        A.NEDStatusID = 2

Индексируются ли какие-либо из этих ограничений (например, DeptID, StartTime, EndTime, NEDStatusID)? Насколько хорошо эти поля выбираются из вашего набора данных?

Если у вас есть 10 млн. строк и NEDStatusID имеет только 10 возможных значений, тогда любое ограничение на это поле всегда будет давать прибл. 1 млн. строк - в этом случае SQL Server может быть проще (и дешевле) выполнить полное сканирование таблицы (сканирование кластерного индекса), особенно если ему также необходимо проверить дополнительные предложения WHERE в той же таблице, которые не проиндексированы либо (StartTime, EndTIme и т. д.).

Марк