Почему оптимизатор запросов полностью игнорирует индексированные индексы представления?

tl; dr ответ: если вы не укажете NOEXPAND, оптимизатор запросов понятия не имеет, что вы отправляете простой выбор из представления. Он должен был бы соответствовать расширению вашего запроса (что все, что он видит) с некоторым индексом представления. Вероятно, не будет беспокоиться, когда это пятистороннее соединение с кучей слепков.

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

SELECT ID, Code1 FROM EntityView Where Code1 > 'NR%';

для вас очевидно, что это может использовать индекс представления, но это не запрос, который видит механизм запросов. Представления автоматически расширяются, если вы не указываете NOEXPAND, поэтому это то, что идет в механизм запросов:

SELECT ID, Code1 FROM (
    SELECT e.ID, 'NR'+CAST(c1.CODE as nvarchar(11)) as Code1, 'NR'+CAST(c2.CODE as nvarchar(11)) as Code2, 'NR'+CAST(c3.CODE as nvarchar(11)) as Code3, 'NR'+CAST(c4.CODE as nvarchar(11)) as Code4, 'NR'+CAST(c5.CODE as nvarchar(11)) as Code5
    FROM dbo.Entity e
        inner join  dbo.Classificator1 c1 on e.ID = c1.ID
        inner join  dbo.Classificator2 c2 on e.ID = c2.ID
        inner join  dbo.Classificator3 c3 on e.ID = c3.ID
        inner join  dbo.Classificator4 c4 on e.ID = c4.ID
        inner join  dbo.Classificator5 c5 on e.ID = c5.ID;
) AS V;

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

имейте в виду, что вы знаете, что соединения и совпадения идентичны в этом запросе и индексах представления, но процессор запросов этого не знает. Он обрабатывает этот запрос так же, как если бы он объединил пять копий Classificator3 или если один из столбцов был " NQ " +CAST(c2.Код как varchar(12)). Сопоставитель индекса представления (предполагая, что он попытался сопоставить этот сложный запрос) должен был бы сопоставить каждую деталь этого запроса с деталями просмотреть индексы таблиц.

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

Если бы мне пришлось угадать, я подозреваю, что сопоставитель индекса представления видит, что результирующие столбцы запроса даже не являются столбцами какой-либо базовой таблицы (из-за приведения) и просто ничего не пытается. добавил: я ошибаюсь. Я просто попробовал предложение Мартина об обновлении статистики, чтобы сделать запрос дорогим, и индекс представления был сопоставлен для некоторых из этих запросов без NOEXPAND. Смотритель умнее, чем я думал! Поэтому проблема заключается в том, что view matcher, вероятно, пытается сложнее сопоставить сложный запрос, если его стоимость очень высока.

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

SELECT ID, Code1 FROM EntityView Where Code1 > 'NR%';

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

(Примечание: ваш код скрипки SQL имеет все 5 ссылок внешнего ключа на одну и ту же таблицу, что, вероятно, не то, что вы хотите.)

используйте подсказку WITH (NOExpand), если вы находитесь в SQL Server Enterprise

ваш запрос будет SELECT * FROM EntityView with (noexpand)