sql server中视图不存数据，执行时内联展开为基表join；“视图导致全表扫描”实为某基表被table/clustered index/index scan频繁访问，需从缓存执行计划xml提取@table属性值，并排除系统伪表，结合逻辑读排序定位真实瓶颈。
查执行计划里真实扫描的物理表名
视图本身不存数据，SQL Server 执行时会把视图定义内联展开成 JOIN 多张基表的语句。所谓“视图导致全表扫描”，实际是展开后某张基表被 Table Scan、Clustered Index Scan 或 Index Scan 频繁扫描。不能只看视图定义里写了哪些表——得从缓存的执行计划 XML 里提取 @Table 属性值。
关键点：
- 目标视图必须已被执行过至少一次，否则
sys.dm_exec_query_stats里没对应记录 -
qp.query_plan.nodes('//RelOp[@LogicalOp="Table Scan"]')这类 XPath 表达式只捕获扫描类操作，不包含Index Seek；如果怀疑是查找效率低，得额外加@LogicalOp="Index Seek"分支 - 结果中要排除
sysallocunits、syscolpars等系统伪表，它们是 SQL Server 内部临时引用，不是业务表
用 sys.dm_exec_query_stats 关联视图名过滤
直接搜 LIKE '%your_view_name%' 是最简单粗暴但有效的方式，前提是视图调用方式是显式命名（比如 SELECT * FROM dbo.v_user_summary），而不是嵌套在更外层视图或动态 SQL 里。
注意几个易错细节：
-
qt.text是完整批处理文本，可能含注释或换行，LIKE要用%v_user_summary%而非精确匹配 - 如果视图名带 schema，比如
sales.v_orders，LIKE条件里必须写全，否则会漏掉 -
OBJECT_NAME(qt.objectid, qt.dbid)返回的是视图对象名，但它可能为空（比如 ad-hoc 查询），所以分组时要保留qt.objectid和qt.dbid一起用
区分 Scan 和 Seek 对性能的真实影响
看到 Table Scan 就认为一定慢，这是常见误解。真正决定代价的是逻辑读（total_logical_reads）和扫描行数，不是操作类型本身。一张只有几百行的小维表，Table Scan 可能比走索引 Seek + Key Lookup 更快。
所以定位重点应该是：
- 按
SUM(qs.total_logical_reads) DESC排序，而不是单纯数exec_count - 如果某张基表在多个不同视图查询中都高频出现，优先检查它的索引覆盖是否合理、统计信息是否过期
-
Index Scan在筛选条件返回大量行时反而是合理选择，盲目加索引可能适得其反
避免被视图定义“带偏”而忽略 JOIN 顺序问题
视图定义里表的书写顺序，和最终执行计划里的驱动表（leading table）完全无关。优化器会重排 JOIN 顺序，而真正引发全表扫描的，往往是那个被选为右表、又没合适索引的基表。
这时单看视图 DDL 没用，必须结合执行计划中的 Nested Loops 或 Hash Match 节点，观察哪一侧输入没有 Seek、只有 Scan，再顺着那个节点往上追溯到具体基表。
最容易被忽略的一点：视图里一个看似简单的 LEFT JOIN，如果右表无关联条件或条件未走索引，就可能让右表变成全量扫描源——而这个右表在视图定义里甚至排在最后。
