列级依赖必须组合查询：sql server用sys.sql_expression_dependencies查表级依赖、sys.dm_sql_referenced_entities查列级依赖；postgresql用explain (verbose)检测失效列；mysql需重建视图验证字段存在性。
直接查 sys.sql_expression_dependencies 只能知道视图用了哪些表，但列级依赖必须搭配 sys.dm_sql_referenced_entities 才能准确定位到具体字段——尤其当视图含 SELECT *、嵌套引用或没加 WITH SCHEMABINDING 时，漏掉列映射等于埋雷。
SQL Server：用两个系统视图组合查表+列
单靠一个视图会丢信息：sys.sql_expression_dependencies 给出表名和跨库线索，sys.dm_sql_referenced_entities 负责拆解列来源。两者缺一不可。
-
sys.sql_expression_dependencies中referenced_id = 0表示对象不存在或名字未解析（比如跨库没写四部分名），此时得看referenced_database_name和referenced_entity_name -
sys.dm_sql_referenced_entities('dbo.MyView', 'OBJECT')的第二个参数必须是字符串字面量'OBJECT'，不能传变量，否则报错 - 结果里
is_ambiguous = 1是危险信号——说明该列引用可能被解析为多个同名对象（比如临时表和永久表共存），需人工确认上下文 - 如果视图定义改过但没执行
sp_refreshsqlmodule 'MyView'，sys.sql_expression_dependencies里的记录不会自动更新，依赖关系滞后
PostgreSQL：靠 EXPLAIN (VERBOSE) 暴露失效列
PG 没内置列级依赖追踪，\d+ view_name 只显示当前结构，不反映底层表字段是否已被删或重命名。真正有效的检测方式是触发解析。
- 运行
EXPLAIN (VERBOSE) SELECT * FROM my_view，看输出里有没有Output: (null)或Attribute number X not found这类提示（部分版本支持） -
pg_get_viewdef('my_view', true)返回原始定义，但注意它不会随ALTER TABLE RENAME COLUMN自动更新，拿到后要手动比对目标表的\d table_name输出 - 别信
pg_views.definition字段——它存的是建视图时的快照，字段删了它还写着
MySQL：盯死 ALGORITHM 和 INFORMATION_SCHEMA.VIEWS
MySQL 视图默认用 UNDEFINED 算法，意味着它根本不校验底层对象是否存在，直到执行才报错。所以“能查出来”不等于“没断链”。
- 查
INFORMATION_SCHEMA.VIEWS的ALGORITHM字段：如果是UNDEFINED或TEMPTABLE，就无法提前发现字段失效；只有MERGE才可能在元数据层面暴露问题 - 重建视图是唯一可靠验证方式：
CREATE OR REPLACE VIEW my_view AS ...，如果底层字段已不存在，这时会立刻报错 -
SHOW CREATE VIEW my_view能看到定义，但无法自动关联到表字段状态，必须人工对照DESCRIBE target_table
跨库、动态 SQL、SELECT * 和嵌套视图这四类场景，任何单一工具都会失效。最稳的做法永远是：先用系统视图捞出所有依赖项，再逐个用查询语句验证字段存在性——机器给线索，人来兜底。
