Запрос представления после создания кластерного индекса по нему все еще приводит к тому же самому плану запроса - PullRequest
0 голосов
/ 19 февраля 2019

У меня есть следующее представление

SET QUOTED_IDENTIFIER ON
SET ANSI_NULLS ON
GO

ALTER VIEW web.vGridHotelBooking
WITH SCHEMABINDING
AS
    SELECT 
        HBK_ID,
        COF_ID,
        COF_CST_ID,
        HTL_Name,
        COF_Data
    FROM 
        web.HotelBooking
    INNER JOIN 
        web.CustomerOfferBundle ON COF_ID = HBK_COF_ID
    INNER JOIN 
        web.Hotel ON COF_HTL_ID = HTL_ID;
GO

CREATE UNIQUE CLUSTERED INDEX [CLI_vGridHotelBooking__HBK_ID] 
ON [web].[vGridHotelBooking] ([HBK_ID]) ON [PRIMARY]
GO

Когда я выполняю инструкцию SELECT * FROM web.vGridHotelBooking, я ожидаю увидеть одно сканирование кластерного индекса, но вместо этого я получаю это

enter image description here

Это тот же план, который я получаю при непосредственном выполнении операторов SELECT.

Что я здесь не так делаю?Я много раз использовал материализованные представления, и у меня не было такой проблемы раньше.

EDIT 1

Выполнение запроса с предложением WHERE также не помогает.

SELECT COF_ID
FROM web.vGridHotelBooking
WHERE COF_ID = '06A41DB5-8F14-4E6C-9084-3009E0626DAA';

enter image description here

РЕДАКТИРОВАТЬ 2

SELECT HBK_ID
FROM web.vGridHotelBooking
WHERE HBK_ID = 1801151518187788

enter image description here

РЕДАКТИРОВАТЬ 3

SELECT HBK_ID
FROM web.vGridHotelBooking WITH (INDEX(CLI_vGridHotelBooking__HBK_ID))
WHERE HBK_ID = 1801151518187788;

enter image description here

РЕДАКТИРОВАНИЕ 4 Выполнение запроса сНа этот раз NOEXPAND дал правильный план.

SELECT *
FROM web.vGridHotelBooking WITH (NOEXPAND)
WHERE HBK_ID = 1801151518187788;

enter image description here

Итак, вопрос - почему это так?Должен ли я беспокоиться об этом?Поскольку таблица CustomerOfferBundle содержит приблизительно 500 000 строк, а таблица Hotel приблизительно 100 000

РЕДАКТИРОВАТЬ 5 enter image description here

1 Ответ

0 голосов
/ 19 февраля 2019

Как обсуждалось в комментариях, вы можете принудительно использовать индексированное представление, используя подсказку WITH (NOEXPAND).

Когда вы это делаете, это показывает, что принудительный план оценивается примерно в 10% от стоимостиисходный план, так что вы можете ожидать, что он будет выбран по соображениям стоимости.

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

См. Ответ Пола Уайта здесь , чтобы узнать больше об этом.При этом также упоминается

сопоставление индексированного представления недоступно на этапе оптимизации 0 (обработка транзакции).

этап обработки транзакции касается запросов, ссылающихся как минимум на 3 таблицы ивложенные циклы объединяются, поэтому для вас вполне возможно, что оптимизация там только что закончилась.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...