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

Question

SQL 2000
Таблица NED имеет внешний ключ к таблице SIGN NED.RowID к SIGN.RowID
Таблица SIGN имеет внешний ключ к таблице SIGN.SignID NED к NED.SignID
RowId и SignID являются кластерными первичными ключами, которые являются идентификаторами GUID (не мой выбор)
ИНЕКЯ является:

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  

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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 и т. д.).

Марк