直接查视图依赖的底层表需通过执行计划分析，因视图无实际数据、执行时被内联展开为多表join，高频扫描的基表才是性能瓶颈根源；应结合sys.dm_exec_query_stats与xml执行计划中的@table属性定位真实被扫描的物理表。
直接查视图依赖的底层表，别猜
SQL Server 的视图本身不存数据，执行时会被展开成 JOIN 多张基表的真实查询。所谓“慢查询高频基表”，本质是视图展开后被反复扫描、过滤或连接的那几张物理表。想定位它，不能靠看视图定义里写了哪些表——得看实际执行时哪几张表贡献了最多逻辑读、扫描行数或 CPU 时间。
用 sys.dm_exec_query_stats + OBJECT_NAME 提取高频访问表
视图查询最终会生成一个可执行计划，而 sys.dm_exec_query_stats 会记录每次执行的累计资源消耗。关键在于：把执行计划里的表对象 ID 反查出来，再按出现频次聚合。
- 先确保目标视图已被执行过（哪怕只一次），否则缓存里没记录
- 运行以下语句，它会找出最近所有涉及该视图的查询中，被扫描次数最多的基表：
SELECT
OBJECT_NAME(qt.objectid, qt.dbid) AS view_name,
t.name AS base_table,
SUM(qs.total_logical_reads) AS total_reads,
COUNT(*) AS exec_count
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
CROSS APPLY (
SELECT DISTINCT
i.value('(@Table)[1]', 'sysname') AS name
FROM qp.query_plan.nodes('//RelOp[@LogicalOp="Clustered Index Scan" or @LogicalOp="Index Scan" or @LogicalOp="Table Scan"]') AS T(i)
WHERE i.value('(@Table)[1]', 'sysname') IS NOT NULL
) t
WHERE qt.text LIKE '%your_view_name%'
AND t.name NOT IN ('sysallocunits', 'syscolpars', 'sysidxstats') -- 排除系统内部伪表
GROUP BY qt.objectid, qt.dbid, t.name
ORDER BY total_reads DESC;
注意：your_view_name 要替换成真实视图名；@LogicalOp 条件覆盖了最常见的全量扫描动作，但不包括 Seek —— 如果你怀疑是索引查找效率低，还得加 "Index Seek" 分支。
为什么不能只看视图定义里的 FROM 子句
视图定义可能写 FROM orders JOIN customers ON ... JOIN products ON ...，但实际执行时，优化器可能因统计信息过期、参数嗅探失效或谓词无法下推，导致某张表被全表扫描，而另外两张只走索引 Seek。更麻烦的是：
- 嵌套视图会让
FROM列表严重失真：A 视图引用 B，B 引用 C，C 里还有 UNION ALL —— 最终执行计划里出现的表，可能远超 A 定义里列出的那几个 - CTE 或子查询在视图里被内联后，可能生成临时命名的派生表（如
Expr1004），根本不在原始定义里 - 某些函数（如
GETDATE()、NEWID()）或 OR 条件会阻止谓词下推，导致本该被提前过滤的表仍参与完整 JOIN
配合 SET STATISTICS XML ON 看真实扫描路径
对可疑视图手动执行一次带实际参数的查询，并开启实际执行计划：
SET STATISTICS XML ON; SELECT TOP 100 * FROM your_view_name WHERE some_col = 'value'; SET STATISTICS XML OFF;
在 SSMS 中查看生成的 XML 执行计划，搜索 <relop logicalop="Table Scan"></relop> 或 <relop logicalop="Clustered Index Scan"></relop> 节点，每个节点下的 @Table 属性就是真实被扫的基表名。重点看：
- 哪个
@Table出现次数最多 - 对应节点的
EstimateRows和ActualRows是否严重偏离（说明统计信息不准） - 是否有大量
Rows Removed by Filter—— 这意味着 WHERE 没走索引，或者条件写法（如UPPER(col) = 'X'）导致索引失效
真正卡住的往往不是 JOIN 的数量，而是某一张表在展开后承担了远超预期的数据搬运量。盯住执行计划里那个“胖节点”，比数视图里写了几个 FROM 更可靠。
