如何查询SQL视图依赖了哪些表-SQL-PHP中文网

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验证。

如何查询sql视图依赖了哪些表

直接查系统视图只能拿到第一层依赖，深层嵌套的表根本不会出现——这是最常踩的坑。

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 依赖）。

Flova

Flova是一款AI文本写作工具，全球首个一体化 AI 视频创作平台。

下载

漏掉 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 返回的结果能反映当前结构——它只是建视图时的快照

真正麻烦的不是查不到，而是查到的“依赖表”可能早就被删了、字段名早就不一样了，而系统还安静地返回空结果——这种静默失效最要命。