最可靠方式是查sys.sql_expression_dependencies，因其记录编译快照、支持嵌套视图和跨架构引用；sys.sql_dependencies已过时，不记录间接依赖且对同义词、动态SQL等支持差。
直接查 sys.sql_expression_dependencies 是最可靠的方式，它能覆盖嵌套视图、跨架构引用，且从 SQL Server 2008 起就稳定可用；用老的 sys.sql_dependencies 会漏掉很多依赖，尤其遇到视图里再引用视图时基本失效。
为什么不能只靠 sys.sql_dependencies
这个旧系统视图不记录“间接依赖”——比如视图 A 引用视图 B，B 再引用表 C，sys.sql_dependencies 通常只显示 A→B，而不会出现 A→C 或 B→C。更麻烦的是，它对同义词、动态SQL、未解析对象返回空或错误标记，is_ambiguous = 1 的行基本没法信任。实际排查时经常发现“明明用了这张表，查询结果里却没它”。
用 sys.sql_expression_dependencies 递归查全路径
核心是把依赖关系当图来遍历：先找目标视图直接引用的对象，再对其中类型为 V（视图）的逐层展开。关键点：
-
referencing_id = OBJECT_ID(@view_name)确保起点准确，注意传入的视图名要带 schema，比如'dbo.v_sales_summary' -
referenced_class = 1表示引用的是对象（非参数、列等），is_ambiguous = 0过滤掉无法解析的引用 - 递归时必须加
NOT EXISTS去重，否则同一张基础表被多层视图引用会反复插入 - 最终结果里
ttype为U才是用户表，V是中间视图，FN/IF是函数——别误把函数当表
示例片段（简化版，去掉了游标，用 CTE 更安全）：
WITH deps AS (
SELECT
referenced_entity_name AS name,
referenced_entity_type AS type,
0 AS level
FROM sys.sql_expression_dependencies d
WHERE d.referencing_id = OBJECT_ID('dbo.v_report')
AND d.referenced_class = 1
AND d.is_ambiguous = 0
UNION ALL
SELECT
d.referenced_entity_name,
d.referenced_entity_type,
deps.level + 1
FROM sys.sql_expression_dependencies d
INNER JOIN deps ON d.referencing_id = OBJECT_ID(deps.name)
WHERE d.referenced_class = 1
AND d.is_ambiguous = 0
AND deps.type = 'V'
)
SELECT DISTINCT name, type
FROM deps
WHERE type = 'U';
常见陷阱和绕不开的细节
这几个地方一错，结果就不可信：
- 视图定义里用了双引号或方括号包裹的名称（如
[Sales].[OrderDetails]），referenced_entity_name只存裸名OrderDetails，但实际可能来自不同 schema——得结合referenced_schema_name字段一起查，否则同名表会混淆 - 如果视图里有
UNION ALL多个 SELECT，且各分支引用不同表，sys.sql_expression_dependencies仍能捕获全部，但旧方法会丢分支 - 索引视图（带唯一聚集索引的视图）要求所有引用表必须显式带 schema，比如
dbo.orders，否则创建失败；但查询依赖时，referenced_schema_name可能为空——这时得 fallback 到sys.objects关联查默认 schema - 权限问题：普通用户查
sys.sql_expression_dependencies只能看到自己有权限访问的对象，DBA 需确认执行账号是否有VIEW DEFINITION权限
真正难的不是写几行 SQL，而是理解“依赖”在 SQL Server 里是编译期快照——视图重建后依赖才更新，改了底层表结构却不重编译视图，依赖信息就 stale 了。所以查完还得人工核对关键表是否存在、列是否匹配，不能全信元数据。
