查 USER_DEPENDENCIES 只能获第一层依赖，因 Oracle 不递归展开；需用 CONNECT BY 递归查询 ALL_DEPENDENCIES 才能获取完整嵌套依赖链，LEVEL 表示深度，末层 REFERENCED_TYPE 多为 TABLE 或 MATERIALIZED VIEW。
直接查 USER_DEPENDENCIES 或 ALL_DEPENDENCIES 只能拿到第一层依赖，看不到嵌套视图背后的表 —— 这是绝大多数人踩坑的起点。
为什么 USER_DEPENDENCIES 查不到深层依赖？
Oracle 的依赖字典不递归展开。比如 V_A 依赖 V_B，V_B 再依赖 T_EMP，那么查 V_A 的 REFERENCED_NAME 只会返回 V_B，T_EMP 完全不会出现。
-
REFERENCED_TYPE = 'VIEW'的记录就是“中转站”，必须继续查它 -
TYPE = 'VIEW'表示当前对象是视图（即你查的那个视图名） -
REFERENCED_TYPE IN ('TABLE', 'MATERIALIZED VIEW')才是最终目标，但只在叶子节点出现 - 没有权限时，
ALL_DEPENDENCIES可能漏掉跨用户对象，DBA_DEPENDENCIES才完整（需 DBA 权限）
查完整依赖链：手写递归 SQL 最可靠
用标准 SQL 实现递归（Oracle 11g+ 支持 CONNECT BY），比 PL/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 = 'YOUR_VIEW_NAME'
AND d.owner = 'OWNER_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;- 把
YOUR_VIEW_NAME和OWNER_NAME替换成实际值（大小写敏感！） -
LEVEL表示嵌套深度：1是直接依赖，2是依赖的依赖 - 最后一层（最高
LEVEL）的REFERENCED_TYPE通常是'TABLE'或'MATERIALIZED VIEW' - 如果结果为空，检查是否拼错视图名，或当前用户没权限访问该视图所属 schema
快速定位物化视图依赖某张表
这不是查视图依赖，而是反向查——哪些物化视图以某张表为基表。这和正向依赖逻辑不同，不能用 CONNECT BY：
- 最准：用
USER_DEPENDENCIES筛REFERENCED_NAME = 'YOUR_TABLE'且TYPE = 'MATERIALIZED VIEW' - 最快但有误报：查
USER_MVIEWS的QUERY字段含表名（WHERE query LIKE '%YOUR_TABLE%'），但注释里有同名也会命中 - 注意
REFERENCED_TYPE在物化视图依赖中是'TABLE'，不是'MATERIALIZED VIEW'；反过来，物化视图本身在TYPE列才是'MATERIALIZED VIEW'
递归深度超过 3 层时，CONNECT BY 查询可能变慢，且 Oracle 默认 MAX_DEPTH 限制为 100 —— 实际上，真正需要深挖到 4 层以上的视图链，往往说明设计已过于耦合，该考虑拆解或加文档了。
