在其上创建聚簇索引后查询视图仍会产生相同的查询计划

Question

我有以下观点

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时，我希望看到单个聚簇索引扫描，但我得到了这个

这与我直接执行SELECT语句时得到的计划相同。

我在这做错了什么？我已多次使用物化视图，之前我没有遇到过这个问题。

编辑1

使用WHERE子句运行查询也没有帮助。

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

编辑2

SELECT HBK_ID
FROM web.vGridHotelBooking
WHERE HBK_ID = 1801151518187788

编辑3

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

编辑4这次使用NOEXPAND运行查询产生了正确的计划。

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

那么问题就是 - 为什么呢？我不得不担心这一个。因为qazxsw poi表中有500万行和qazxsw poi表顶点100 000

编辑5 CustomerOfferBundle

Answer 1

如评论中所述，您可以使用Hotel提示强制使用索引视图。

当您这样做时，它表明强制计划估计大约是原计划成本的10％，因此您可能希望在成本基础上选择此计划。

但是，编译的工作方式是首先展开视图定义，然后在优化过程中稍后可能会或可能不会匹配回索引视图。对于廉价计划，优化可能会在没有达到该步骤的情况下结束。

有关详细信息，请参阅。这也提到了

索引视图匹配在优化阶段0（事务处理）中不可用。

事务处理步骤涉及引用至少3个表和嵌套循环连接的查询，因此完全可以在那里优化结束。

如果增加表的大小（尤其是WITH (NOEXPAND)）并且原始计划变得更加昂贵，则会在优化上花费更多时间，并且索引视图可能最终匹配。

您始终可以使用提示来确定。