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

Предикаты распарились в DATEPART и индекс был успешно заюзан.
Для доп. анализа вот еще

(54429 rows affected)
Table 'RETURNED_ITEM_2'. Scan count 5, logical reads 169985, physical reads 1514, read-ahead reads 6626, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 1140 ms, elapsed time = 1231 ms.
CPU time = 0 ms, elapsed time = 0 ms.

(54429 rows affected)
Table 'RETURNED_ITEM_2'. Scan count 5, logical reads 11525, physical reads 1, read-ahead reads 11646, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 593 ms, elapsed time = 1248 ms.

Гавриленко Сергей Алексеевич,

Обычный индекс по полю datetime (да, дамп базы из 2005 года)

invm,

Эффекта нет, да и это база на моем лэптопе.
Весь вопрос скорее в том, что может кто знает, почему SQL Server пытается через datepart насильно индекс попользовать.
Может быть какой программист подумал "а что это у нас клиенты жалуются, что MONTH и YEAR не используют индекс по дате? давай ка выкатим апдейт и покажем им, что мы умеем умно запросы парсить" :D

Есть теория, что планировщик, при виде Year и Month, полагает, что ему будет достаточно первых 3 байт из искомого поля для поиска и сравнения. И достать эти 3 байта из индекса выглядит как раз очень соблазнительной перспективой