递归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 的数字序列（仅作语法验证）：

FROM

• 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。