用 with recursive 创建视图时，必须显式声明列名；postgresql 和 sqlite 支持，mysql（截至 8.0.33）不支持直接在视图中使用递归 cte，且需注意索引、终止条件、数据类型一致性和跨库兼容性问题。
用 WITH RECURSIVE 创建视图时，必须显式声明列名
PostgreSQL 和 SQLite 支持在 CREATE VIEW 中嵌套 WITH RECURSIVE，但 MySQL（截至 8.0.33）不支持直接在视图定义里写递归 CTE。常见错误是省略列别名，导致视图创建失败或后续查询报错 column "xxx" does not exist。
正确写法必须为递归 CTE 的最终 SELECT 显式指定列名，且与 CREATE VIEW 的列列表严格对应：
CREATE VIEW employee_hierarchy AS WITH RECURSIVE org AS ( SELECT id, name, manager_id, 0 AS level FROM employees WHERE manager_id IS NULL UNION ALL SELECT e.id, e.name, e.manager_id, o.level + 1 FROM employees e INNER JOIN org o ON e.manager_id = o.id ) SELECT id, name, manager_id, level FROM org;
- 不能省略
SELECT id, name, manager_id, level FROM org这一层包装，否则 PostgreSQL 会拒绝创建视图 - SQLite 要求视图定义中所有列都有明确别名，
level + 1必须带AS level - 如果原始表字段类型存在隐式转换（如
manager_id是TEXT而id是INTEGER），递归部分的JOIN条件可能静默失败——务必检查数据类型一致性
MySQL 用户无法直接在视图中用 WITH RECURSIVE，得换思路
MySQL 8.0+ 支持 WITH RECURSIVE，但语法限制严格：CREATE VIEW 不接受顶层 CTE。试图执行类似语句会报错 ERROR 1349 (HY000): View's SELECT contains a recursive WITH clause。
可行替代方案有两类：
- 封装成存储过程或函数，返回临时表；但无法被其他查询
JOIN，实用性低 - 改用内联方式：把递归逻辑写进业务查询，再用该查询构建“伪视图”——即建一个普通视图，内容是带完整
WITH RECURSIVE的SELECT，但注意这不是标准视图，而是应用层约定 - 更稳妥的做法是，在应用代码中预生成扁平化结果表（如
employee_paths），用触发器或定时任务维护，视图则基于这张表——牺牲实时性换稳定性
递归视图性能差？关键在索引和终止条件
递归视图慢，往往不是语法问题，而是执行计划失控。PostgreSQL 对 WITH RECURSIVE 的优化依赖基础表上的索引和递归深度控制。
- 确保递归引用字段（如
manager_id）上有索引，否则每次迭代都要全表扫描 - 没有
WHERE限制递归起点时，初始查询可能拉取过多根节点，拖慢整个过程 - PostgreSQL 默认无深度限制，若数据存在环（A→B→A），会无限循环直至超时；应加
level 类防护，或用 <code>ARRAY[id]记录路径检测环 - SQLite 的递归默认最多 1000 层，可通过
PRAGMA recursive_triggers = ON配合MAX_RECURSION_DEPTH调整，但不推荐盲目提高
跨数据库移植递归视图前，先验证 WITH RECURSIVE 是否真被支持
看似标准的 SQL，实际兼容性极差。除了 MySQL 视图不支持外，还有几个隐藏坑：
- SQL Server 用
WITH+CTE支持递归，但不支持在CREATE VIEW中嵌套；需用VIEW包裹外部WITH查询，且必须加OPTION (MAXRECURSION n) - Oracle 用
CONNECT BY，语法完全不同，无法直译；强行转写易漏掉START WITH或CONNECT BY PRIOR方向 - 即使同是 PostgreSQL，高版本（14+）对递归 CTE 的物化策略更激进，某些旧版能跑的视图在新版本可能内存暴涨——建议在
EXPLAIN ANALYZE中观察CTE Scan的实际行数
最常被忽略的是：递归视图一旦被多个并发查询调用，每个查询都会独立执行整套递归逻辑，不会共享中间结果。如果业务需要高频访问层级关系，缓存或物化是绕不开的一步。
