Oracle需用CONNECT BY递归查ALL_DEPENDENCIES，PostgreSQL须用pg_depend+deptype='n'过滤并递归CTE，SQL Server依赖sys.sql_expression_dependencies与sys.dm_sql_referenced_entities组合，MySQL只能靠CREATE OR REPLACE VIEW验证。
直接查系统视图只能拿到第一层依赖，深层嵌套的表根本不会出现——这是最常踩的坑。
Oracle：必须用 CONNECT BY 递归查 ALL_DEPENDENCIES
USER_DEPENDENCIES 和 ALL_DEPENDENCIES 都不递归展开。比如视图 V_A 依赖 V_B，V_B 再依赖 T_EMP，那么查 V_A 的 REFERENCED_NAME 只会返回 V_B，T_EMP 完全不露头。
-
REFERENCED_TYPE = 'VIEW'是中转站，得继续查它；REFERENCED_TYPE IN ('TABLE', 'MATERIALIZED VIEW')才是最终目标 - 权限不足时，
ALL_DEPENDENCIES会漏掉跨用户对象，DBA_DEPENDENCIES才完整（需 DBA 权限） - 必须写全
OWNER_NAME和大小写，否则START WITH匹配失败
实操 SQL：
SELECT DISTINCT LEVEL dep_level,
d.name view_name,
d.referenced_owner,
d.referenced_name,
d.referenced_type
FROM all_dependencies d
START WITH d.name = 'MY_VIEW' AND d.owner = 'SCHEMA_NAME' AND d.type = 'VIEW'
CONNECT BY PRIOR d.referenced_name = d.name
AND PRIOR d.referenced_owner = d.owner
AND PRIOR d.referenced_type = 'VIEW'
ORDER BY LEVEL, d.referenced_name;
PostgreSQL：绕开 pg_views，直击 pg_depend + 递归 CTE
pg_views 和 INFORMATION_SCHEMA.VIEWS 存的是建视图时的 SQL 快照，字段删了、表重命名了，它们还显示“存在”，完全不可信。真实依赖只在 pg_depend 里，且必须过滤 deptype = 'n'（normal 依赖）。
- 漏掉
refclassid = 'pg_class'::regclass AND classid = 'pg_class'::regclass，会混入大量系统级噪音（deptype = 'a'或'i'） - 小于 16384 的
refobjid基本是系统对象，加refobjid >= 16384才干净 - 物化视图（
relkind = 'm'）和外部表（relkind = 'f'）不走pg_depend标准链路，得额外查pg_matviews或pg_foreign_table
SQL Server：sys.sql_expression_dependencies + sys.dm_sql_referenced_entities 组合查
单靠 sys.sql_expression_dependencies 只能知道用了哪些表，列级依赖必须搭配 sys.dm_sql_referenced_entities 才准——尤其当视图含 SELECT * 或没加 WITH SCHEMABINDING 时。
-
sys.dm_sql_referenced_entities('dbo.MyView', 'OBJECT')第二个参数必须是字符串字面量'OBJECT'，不能传变量 -
is_ambiguous = 1是危险信号：说明该列可能被解析为多个同名对象（比如临时表和永久表共存） - 视图定义改过但没执行
sp_refreshsqlmodule 'MyView'，依赖记录不会自动更新，关系滞后
MySQL：别信 INFORMATION_SCHEMA.VIEWS，重建才是唯一验证方式
MySQL 视图默认用 ALGORITHM = UNDEFINED，意味着它根本不校验底层对象是否存在，直到执行才报错。“能查出来”不等于“没断链”。
-
INFORMATION_SCHEMA.VIEWS.ALGORITHM字段值为UNDEFINED或TEMPTABLE时，无法提前发现字段失效 -
CREATE OR REPLACE VIEW my_view AS ...是唯一可靠验证：如果底层字段已不存在，这时立刻报错 - 别指望
SHOW CREATE VIEW返回的结果能反映当前结构——它只是建视图时的快照
真正麻烦的不是查不到，而是查到的“依赖表”可能早就被删了、字段名早就不一样了，而系统还安静地返回空结果——这种静默失效最要命。
