最稳的视图依赖分析需三步：先用sys.sql_expression_dependencies查对象级依赖，再用sys.dm_sql_referenced_entities查列级映射，最后用sys.dm_exec_describe_first_result_set验证实际可执行性与列一致性。
直接用 sys.sql_expression_dependencies 查，别信 SSMS 右键“查看依赖关系”——它对跨库、SELECT *、动态拼接的引用基本不报，改表时删错字段才发现十几个视图全挂了。
查视图依赖哪些表和数据库，用 sys.sql_expression_dependencies
这是最稳的第一步，覆盖所有显式按名引用，哪怕被引用的表已经删了，只要定义里写过，它就还在记录里。
-
referencing_id = OBJECT_ID('dbo.MyView')是必须条件，记得加架构名，否则查不到 -
referenced_database_name为空表示依赖在当前库；非空（比如'OtherDB'）就得确认该库是否存在、当前登录用户是否有权限访问 -
referenced_id = 0是危险信号：说明名字没解析出来，常见于跨库没写四部分名（如OtherDB.dbo.TableA写成TableA）或对象根本不存在 -
is_ambiguous = 1表示 SQL Server 拿不准该引用指向哪个对象（比如同名的临时表和永久表共存），得人工核对上下文
查视图具体用了哪些列，用 sys.dm_sql_referenced_entities
当你要确认 “视图 A 的 FullName 列是不是来自表 B 的 FirstName + LastName”，或者视图用了 WITH SCHEMABINDING 但你不确定列映射是否还有效，这个函数是唯一能推导列级依赖的。
- 调用格式固定：
SELECT * FROM sys.dm_sql_referenced_entities('dbo.MyView', 'OBJECT')，第二个参数必须是字符串字面量'OBJECT'，不能变量传入 - 结果里的
referenced_minor_id > 0表示列级引用；referenced_minor_id = 0是对象级（表/视图本身） - 它会尝试解析 SQL 表达式，哪怕目标表当前不可用也能还原意图——但跨服务器依赖它不支持，
referenced_server_name永远为NULL
验证依赖项是否真实存在且列没失效，用 sys.dm_exec_describe_first_result_set
查完依赖只是知道“它写了什么”，还得验证“写的还能不能跑”。尤其当你刚重命名了基表字段，视图可能仍能 SELECT，但返回 NULL 或类型不匹配。
- 对每个依赖项执行：
sys.dm_exec_describe_first_result_set(N'SELECT * FROM [db].[schema].[table]', NULL, 0)，第三个参数设为0表示只解析不执行 - 重点看
is_hidden = 0且column_ordinal > 0的行，比对列名、数据类型、is_nullable是否与视图预期一致 - 如果依赖跨库，
[db]必须显式写上，否则默认查当前库，结果就错了
真正容易被忽略的是：SQL Server 不会在你改基表时自动刷新视图元数据。哪怕你 ALTER TABLE ... RENAME COLUMN 了，sp_helptext 里看到的视图定义还是旧的，sys.columns 里也查不到变化——必须靠上面三步组合验证，缺一不可。
