数据库拒绝创建循环依赖视图（如A依赖B、B又依赖A），在CREATE VIEW时即报ORA-04045等错；根本原因是解析依赖图时检测到环，需拆分逻辑、抽离共用子查询为物化视图或表。
视图 A 依赖视图 B，B 又依赖 A：直接报错 ORA-04045 或 ERROR: circular view dependency
PostgreSQL、Oracle、SQL Server 都会拒绝创建这种循环引用的视图。不是延迟报错，是 CREATE VIEW 阶段就拦住——数据库内核在解析依赖图时检测到环，直接拒绝入库。
常见诱因是“为复用临时逻辑”把两个本该扁平的查询互相引用，比如 v_user_summary 引用了 v_active_orders，而后者又通过 WHERE user_id IN (SELECT id FROM v_user_summary) 拉回前者。
- 别试图用 WITH RECURSIVE 绕过——它只适用于自引用（同一视图查自己），不解决跨视图循环
- 删掉中间视图，把逻辑压进最终查询里，是最快速验证是否真需要拆分的办法
- 如果必须保留多层抽象，把共用子逻辑抽成物化视图（如 PostgreSQL 的
CREATE MATERIALIZED VIEW）或普通表（带定时刷新），切断依赖链
拆分视图时字段名冲突导致 column "x" specified more than once
两个基础视图都 SELECT 出了 id 和 created_at，上层视图 JOIN 它们后没显式别名，PostgreSQL 就直接报错；SQL Server 更严格，连 SELECT * 都不允许出现在有 JOIN 的视图定义中。
这不是语法错误，是语义歧义：数据库无法确定你后续想引用的是哪一边的 id。
- 所有 JOIN 后的字段必须显式别名，例如
u.id AS user_id,o.id AS order_id - 避免在视图里用
SELECT *，哪怕源表结构稳定——加个新字段就可能让下游视图崩 - 如果视图只是为简化 JOIN，考虑用 SQL 函数（如 PostgreSQL 的
CREATE FUNCTION ... RETURNS TABLE）替代，函数调用时字段名由调用方控制
视图嵌套过深引发性能断崖：执行计划显示 Nested Loop 套 5 层
一个视图查另一个视图，再查第三个……每层都带 WHERE 或 JOIN，优化器容易放弃推导，退化成逐层物化中间结果。你看到的执行时间暴增，往往不是数据量大，而是规划器“不敢优化”。
典型信号是 EXPLAIN 输出里出现大量 Materialize 节点，且 cost 预估跳变剧烈。
- 用
pg_stat_statements（PG）或sys.dm_exec_query_stats（SQL Server）抓出慢的视图名，再对它单独 EXPLAIN - 把三层视图手动展开成单条 SQL，对比执行计划——如果快很多，说明嵌套破坏了谓词下推
- 关键过滤条件（如
WHERE tenant_id = ?）尽量写在最外层视图，避免被锁死在内层
MySQL 8.0+ 视图无法用 WITH CHECK OPTION 实现权限隔离
你以为加了 WITH CHECK OPTION 就能限制 INSERT/UPDATE 只影响某租户数据？错了。它只校验 DML 是否符合视图定义里的 WHERE 条件，不阻止用户绕过视图、直接操作基表。
更麻烦的是：MySQL 的 CHECK OPTION 对子查询、JOIN 视图支持弱，常静默失效。
- 真正要隔离数据，得靠行级安全策略（如 PostgreSQL 的
ROW SECURITY POLICY）或应用层强制走视图入口 - 如果必须用 MySQL，把视图 + 存储过程组合：INSERT 封装进 SP，SP 内部校验 tenant_id 并显式拼入 WHERE
-
WITH CHECK OPTION在单表简单视图里才可靠，JOIN 多表时建议直接弃用
循环依赖的本质不是语法问题，是架构里“谁该知道谁”的边界模糊了。拆的时候别只盯着 SQL 改写，先问一句：这两个逻辑，真的需要彼此看见吗？
