как это происходит SP SQL Server

Question

Я получаю что-то странное. я управлял этим sql:

SELECT   Id , GameTypeId , PlayerId , BetAmount , Profit ,
         DateAndTime
FROM     Results
WHERE    DateAndTime >= DATEADD (DAY , -1 , SYSDATETIME ())
         AND
         DateAndTime < SYSDATETIME ()
ORDER BY DateAndTime ASC;

у меня есть некластерный индекс в столбце даты
и фактическое количество возвращаемых строк составляет
672 строки из 1600016 строк в таблице. (примерный ряд был 1)

после этого я запустил этот sql:

declare @d DATETIME2(7) 
set @d = DATEADD (DAY , -1 , SYSDATETIME ())
declare  @d2 DATETIME2(7)
set @d2  = SYSDATETIME ()

SELECT   Id , GameTypeId , PlayerId , BetAmount , Profit ,
         DateAndTime
FROM     Results
WHERE    DateAndTime >= @d
         AND
         DateAndTime < @d2
ORDER BY DateAndTime ASC;

и фактический план выполнения был СКАНИРОВАНИЕ !!! и фактическое количество возвращаемых строк составляет
672 строки из 1600016 строк в таблице. (примерный ряд был 144000 rwws)

Кто-то знает, что здесь произошло?!?!?

Answer 1

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

Answer 2

Try

declare @d DATETIME2(7) 
set @d = DATEADD (DAY , -1 , SYSDATETIME ())
declare  @d2 DATETIME2(7)
set @d2  = SYSDATETIME ()

SELECT   Id , GameTypeId , PlayerId , BetAmount , Profit ,
         DateAndTime
FROM     Results
WHERE    DateAndTime >= @d
         AND
         DateAndTime < @d2
ORDER BY DateAndTime ASC
OPTION (RECOMPILE);

Это перекомпилирует план для оператора, как только будут известны значения переменных, и, таким образом, позволит использовать точные оценки мощности.Если вы знаете, что вы всегда будете выбирать очень маленький процент, вы можете просто использовать подсказку FORCESEEK (если SQL Server 2008) вместо этого, чтобы избежать перекомпиляции, но использование этой подсказки может быть катастрофически плохим для больших диапазонов из-за количества ключевых запросов!

Answer 3

В дополнение к ответу Мартина ...

Results.DateAndTime также должно быть datetime2 (7) согласно переменным.если нет, то, скорее всего, у вас проблема приоритета типа данных

Answer 4

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

Answer 5

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

Итак, вопрос в том, почему число предполагаемых строк слишком далеко?

Я, к сожалению, пока не очень глубоко разбираюсь в SQL Server. Однако я бы сказал, что это из-за параметров связывания; это может сильно повлиять на оценки мощности (строки оценок) (по крайней мере, в других базах данных).