递归CTE必须包含锚点和递归成员，且递归成员需引用自身；MySQL 8.0+才支持并强制WITH RECURSIVE，各数据库语法兼容性差，不可跨库通用，权限配置不当会导致运行时报错。
递归CTE必须包含锚点和递归成员，且递归成员需引用自身
SQL 中的递归 CTE（Common Table Expression）不是简单加个 WITH RECURSIVE 就能跑通。PostgreSQL、SQL Server、Oracle、SQLite 支持递归 CTE，但 MySQL 8.0+ 才支持，且必须显式声明 WITH RECURSIVE ——漏写 RECURSIVE 关键字会直接报错 ERROR: invalid reference to FROM-clause entry 或类似提示。
结构上必须满足：一个锚点查询（不依赖 CTE 名） + 一个递归查询（UNION ALL 连接，且 SELECT 中必须出现对 CTE 名的引用）。递归成员不能含聚合、GROUP BY、ORDER BY（除非在子查询里）、窗口函数（多数引擎不允），否则报错 recursive reference must not appear in subquery 等。
示例：生成 1~5 的数字序列（仅作语法验证）：
WITH RECURSIVE nums(n) AS ( SELECT 1 UNION ALL SELECT n + 1 FROM nums WHERE n < 5 ) SELECT * FROM nums;
封装为视图时，递归CTE必须作为视图定义的顶层查询
不能把递归 CTE 写在视图里的子查询中，也不能嵌套在 FROM 子句的派生表里。视图定义必须以 WITH RECURSIVE ... AS (...) SELECT ... 开头，且 SELECT 必须直接从该 CTE 引用，否则 PostgreSQL 报 invalid reference to FROM-clause entry，SQL Server 报 Recursive common table expression '<name>' does not contain a recursive member。
常见错误写法：CREATE VIEW v AS SELECT * FROM (WITH RECURSIVE ...) ——这会让 CTE 作用域被限制在子查询内，失去递归上下文。
正确封装方式（以组织架构树为例）：
CREATE VIEW org_tree AS WITH RECURSIVE tree AS ( SELECT id, name, manager_id, 1 AS level FROM employees WHERE manager_id IS NULL UNION ALL SELECT e.id, e.name, e.manager_id, t.level + 1 FROM employees e INNER JOIN tree t ON e.manager_id = t.id ) SELECT id, name, manager_id, level FROM tree;
视图中递归深度控制靠 WHERE 条件，而非 MAXRECURSION
SQL Server 有 OPTION (MAXRECURSION n)，但它**不能用于视图定义中**——视图里不允许出现 OPTION 提示。想限制深度，只能在递归 CTE 的 WHERE 子句里硬编码或传参（如果数据库支持参数化视图，如 PostgreSQL 的物化视图 + 函数封装，但原生视图不行）。
例如防止无限循环，应在递归分支加层级上限或路径防重判断：
WHERE t.level —— 简单层级截断-
AND e.id != t.id（配合路径数组更稳妥）—— 防自环，尤其当数据存在脏关联时 - PostgreSQL 可用
ARRAY[id]和@> ARRAY[e.id]检查路径是否已含当前节点
没加防护的递归视图一旦底层数据出现循环引用（如 A → B → A），查询时会直接超时或报 maximum recursion depth exceeded。
跨数据库兼容性差，别指望一套 SQL 在 MySQL/PG/SQL Server 里都跑通
MySQL 要求 WITH RECURSIVE；PostgreSQL 允许省略 RECURSIVE 但建议加上；SQL Server 强制要求且不支持 LIMIT 类语法；Oracle 用 CONNECT BY，根本不认 CTE 递归写法。所以“封装为公共视图”这个动作本身，在多数据库环境中几乎不可行。
如果真要兼顾，只能放弃递归 CTE，改用应用层迭代或数据库特定方案（如 PostgreSQL 的 ltree 扩展、SQL Server 的 HIERARCHYID）。另外注意：视图里无法传参，想动态指定根节点，只能用函数包装（如 CREATE FUNCTION get_subtree(root_id INT) RETURNS TABLE...），但这已不是“视图”了。
真正容易被忽略的是权限——递归视图执行时会检查基表（如 employees）的 SELECT 权限，且是**定义者权限还是调用者权限**取决于数据库（PostgreSQL 默认调用者权限，SQL Server 视图可设 EXECUTE AS），权限配置不到位，视图看似创建成功，一查就报 permission denied for table employees。
