SQL Server 依赖分析需组合使用 sys.sql_expression_dependencies 和 sys.dm_sql_referenced_entities，因 sysdepends 已过时且不可靠；影响分析必须验证对象存在性、歧义引用、动态SQL及架构绑定状态。
SQL Server 中没有“自动发现依赖项”的运行时机制，依赖关系是编译时快照，不是动态追踪；影响分析报告必须靠组合查询 sys.sql_expression_dependencies 和 sys.dm_sql_referenced_entities 手动拼装，不能靠 SSMS 右键或单个函数一键生成。
为什么 sysdepends 不能用，连看都不能看
它从 SQL Server 2005 起就标记为“仅供向后兼容”，数据来自过时的编译缓存，对 CTE、窗口函数、OFFSET-FETCH、同义词、跨库引用完全失能。更危险的是：它会把间接依赖（视图 A → 视图 B → 表 C）直接记成 A → C，跳过中间层——你删表 C 前查 sysdepends，以为只有 A 在用，结果 B 也崩了。
查视图依赖表的正确 SQL 写法
两个视图/函数各司其职，必须配合使用：
-
sys.sql_expression_dependencies是起点：它记录创建/修改视图时写死的名称引用，哪怕被引用的表已删、跨库未连通，只要定义里写了SELECT * FROM OtherDB.dbo.T，这条记录就在 -
sys.dm_sql_referenced_entities是验证：它实时解析视图定义文本，能告诉你“当前这版定义实际能访问哪些对象”，对未存在对象也敢推导（比如表被删但视图没重编译）
典型组合查法（查 dbo.v_sales_summary 依赖）：
SELECT
d.referenced_schema_name,
d.referenced_entity_name,
d.referenced_database_name,
r.referenced_minor_name -- 列级引用（如 SELECT a,b FROM t）
FROM sys.sql_expression_dependencies d
LEFT JOIN sys.dm_sql_referenced_entities('dbo.v_sales_summary', 'OBJECT') r
ON d.referenced_id = r.referenced_id
WHERE d.referencing_id = OBJECT_ID('dbo.v_sales_summary')
AND d.referenced_class IN (1, 2);影响分析报告要覆盖哪些关键点
生产环境做变更前，光知道“视图用了哪些表”远远不够，必须确认以下几件事：
- 被依赖对象是否真实存在：
referenced_id为 NULL 或 0 时，说明表名无效、跨库未加三段式名、或对象已被删 - 是否存在歧义引用：
sys.dm_sql_referenced_entities返回的is_ambiguous = 1行必须人工核对——比如同名临时表和永久表共存，SQL Server 运行时按 scope 解析，你改永久表可能不影响当前执行，但下次会变 - 是否含不可捕获依赖：视图里有
EXEC('SELECT * FROM ' + @tbl)或sp_executesql，这两个函数完全不识别，得去sys.sql_modules.definition里正则扫字符串 - 架构绑定状态：
OBJECTPROPERTY(OBJECT_ID('v_name'), 'IsSchemaBound')返回 1 才代表依赖强制锁定，否则改底层表结构（如删列）可能只让视图变INVALID，不报错也不预警
真正麻烦的从来不是查出依赖，而是那些查不到的——动态拼接、加密视图、未三段式跨库引用，这些地方漏掉一个，上线后就是生产事故。别信 SSMS 的“查看依赖关系”，它连 SELECT * 展开后的列都经常报错漏列。
