应使用sys.sql_expression_dependencies配合递归CTE查清v1→v2→v3链路，先查单层依赖并过滤referenced_class=1，再逐层用OBJECT_ID转换视图名递归展开，每层须用sys.dm_exec_describe_first_result_set验证列有效性。
SQL Server 怎么查清 v1 → v2 → v3 的完整依赖链
别用 sp_depends，它在 SQL Server 2016+ 已弃用，对嵌套依赖返回空或错乱结果。真正可用的是 sys.sql_expression_dependencies 配合递归 CTE。
先查单层依赖：SELECT referenced_entity_name, referenced_schema_name FROM sys.sql_expression_dependencies WHERE referencing_id = OBJECT_ID('v1') AND referenced_class = 1；referenced_class = 1 过滤掉参数、类型等干扰项。
- 递归展开时必须用
OBJECT_ID()转换视图名为 ID，不能直接用名字匹配 - 每层都要手动验证列是否存在：对
v2执行sys.dm_exec_describe_first_result_set(N'SELECT * FROM v2', NULL, 0)，确认上层引用的字段名和类型没被删改或重命名 - 如果某层返回空结果，大概率是视图定义里用了未授权对象（如跨库表没加权限），不是没依赖，而是查不到
PostgreSQL 中 pg_depend 为什么总返回一堆无关记录
pg_depend 默认包含索引、约束、触发器等系统自动生成的依赖，真正反映视图间引用的只有 deptype = 'n'（normal）的记录。不加过滤，90% 是噪音。
正确写法必须同时满足：deptype = 'n' 且 classid = 'pg_class'::regclass 且 refclassid = 'pg_class'::regclass，确保两端都是视图或表，不是索引或序列。
- 递归查询时一定要加
AND depth ，防止无限循环炸栈——人工排查超过 5 层就该重构了 -
pg_views完全没用，它只存原始定义文本，不解析依赖；靠正则从definition字段扒名字容易漏掉 schema 前缀或反引号 - 物化视图和外部表不会出现在标准依赖链里，得单独查
pg_matviews和pg_foreign_table并手动衔接
MySQL 只能靠 SHOW CREATE VIEW 正则解析？怎么避免漏匹配
MySQL 不维护任何依赖元数据，INFORMATION_SCHEMA.VIEWS.VIEW_DEFINITION 字段甚至可能被截断，SHOW CREATE VIEW 是唯一可靠入口。
执行 SHOW CREATE VIEW v_kpi 后，提取 SELECT 子句，再用正则匹配 FROM\s+`?(\w+)`? 或 JOIN\s+`?(\w+)`?，但必须排除带点号的 db.schema.table 形式。
- 注意反引号包围的视图名（如
`v_user`）和大小写敏感问题，正则要加i标志 - 如果视图用了
ALGORITHM = TEMPTABLE，说明它无法合并，上层视图必然重算全部中间结果——这不是依赖问题，但常被忽略为性能隐患 - 改完底层视图后，必须手动
CREATE OR REPLACE VIEW上层，MySQL 不自动刷新依赖链，旧结构会缓存到下次重建
查到依赖链后怎么判断有没有循环
循环不是靠工具报错才暴露的，而是运行时报 ERROR: circular view dependency（PostgreSQL）、ORA-04045（Oracle）或创建时直接拒绝（SQL Server）。工具只能帮你画出链路，是否成环得靠人眼比对。
把所有路径列出来，比如 v_report → v_summary → v_base → v_report，只要起点和终点相同，就是环。重点盯住 WHERE 子句里的子查询，比如 WHERE id IN (SELECT id FROM v_report) ——这种隐式引用 pg_depend 根本抓不到，因为它是运行时逻辑，不是元数据依赖。
- 别指望
pg_depend自动穿透 CTE 或子查询，它只管顶层FROM和JOIN显式对象 - 跨 schema 视图引用容易被忽略：创建时
search_path不同，导致依赖关系在元数据里“断开”，但运行时又能找到——这种伪循环更难定位 - 最稳妥的办法是手动展开三层以上视图成单条 SQL，执行前先看语法是否合法；如果
SELECT *报column "x" specified more than once，往往意味着两个基础视图输出同名字段，而上层没做别名，这是循环设计的典型症状
