CTE必须后接主查询，正确结构为WITH...SELECT或WITH...INSERT/UPDATE/DELETE...SELECT；多CTE用逗号分隔；递归CTE需UNION ALL+层级限制；CTE不跨语句复用，非物化视图。
CTE怎么写才不会报错：WITH后面必须跟SELECT
很多人写完 WITH t1 AS (SELECT ...) 就直接结束了，结果执行报错——因为CTE本身不执行，它只是定义，后面必须接一个主查询。常见错误是把CTE当成了独立语句，或者在中间加了 INSERT / UPDATE 而没用 SELECT 衔接。
正确结构只有两种：要么 WITH ... SELECT，要么 WITH ... INSERT/UPDATE/DELETE ... SELECT（某些数据库支持）。PostgreSQL、SQL Server、Snowflake 都严格要求 CTE 后紧跟一个顶层 SELECT；MySQL 8.0+ 也一样，但老版本不支持 CTE，直接报错 ERROR 1349 (HY000): View's SELECT contains a subquery in the FROM clause。
- 别在 CTE 定义后直接写
WHERE或ORDER BY - 多个 CTE 用逗号分隔，不是用
;或GO - CTE 名不能和已有表名/视图名冲突，否则部分引擎（如 Presto）会优先解析为表，导致列找不到
递归CTE的终止条件写在哪：必须用UNION ALL + WHERE限制层级
链式查询最常用递归 CTE，比如查组织架构上下级、BOM 展开、路径遍历。但递归不设终止条件，轻则超时，重则栈溢出报错 Maximum recursion exceeded（SQL Server）或 Recursive query aborted after 1001 iterations（PostgreSQL）。
关键点在于：递归分支必须出现在 UNION ALL 的第二部分，且递归体里要主动加 WHERE level 这类硬限制，不能只靠连接条件“自然断开”。很多同学以为只要父ID不等于子ID就安全，其实环形引用一出现就死循环。
- 第一部分（锚点）必须是不含自引用的初始集，例如
SELECT id, manager_id, 1 as level FROM emp WHERE manager_id IS NULL - 第二部分（递归体）必须用
UNION ALL，不能用UNION（会去重，破坏递归逻辑） - 层级计数字段（如
level）必须在两部分都 select 出来，并在递归体中+ 1 - PostgreSQL 需显式加
SEARCH DEPTH FIRST BY id SET ordercol才能稳定排序，否则输出顺序不可控
CTE和子查询性能差多少：多数情况没差别，但嵌套深了会拖慢优化器
有人觉得 CTE 是“语法糖”，性能一定不如内联子查询；也有人觉得 CTE 能物化，更快。实际取决于数据库引擎——PostgreSQL 会按需物化（除非加 MATERIALIZED 提示），而 SQL Server 默认不物化，Oracle 12c+ 对 WITH 子句有单独代价估算。
真正影响性能的是写法：如果同一个 CTE 被主查询引用多次（比如 SELECT * FROM t1 JOIN t1 ON ...），PostgreSQL 可能重复计算；而手写两个相同子查询，优化器有时能识别并复用。但反过来，CTE 能让复杂逻辑分层，避免 (SELECT ...) AS x, (SELECT ...) AS y 这种写法导致优化器无法合并扫描。
- 别为了“看着清楚”把简单过滤拆成 CTE，比如
WITH filtered AS (SELECT * FROM t WHERE status = 'A')再SELECT * FROM filtered—— 没必要 - 涉及窗口函数时，CTE 可以先算好分区字段，再在外层排序，比全写在一层里更容易被优化
- BigQuery 中 CTE 默认不物化，但加
/*+ materialize */注释可强制缓存中间结果
跨库/跨Schema引用CTE：别指望CTE能当视图用
CTE 生命周期只在单条语句内，不能被其他 SQL 引用，也不能在存储过程中跨语句复用。有人想在一个脚本里定义一次 CTE，后面几个 SELECT 都用它，结果第二个 SELECT 直接报错 relation "t1" does not exist。
如果真需要复用逻辑，方案只有三个：建临时表（CREATE TEMP TABLE）、建视图（CREATE VIEW）、或者把 CTE 内容复制粘贴。临时表适合大数据量中间结果，视图适合权限可控的共享逻辑，而 CTE 本质就是“这一条 SQL 里的局部变量”。
- CTE 中不能引用当前会话外创建的临时表（某些引擎如 Redshift 不允许）
- 在事务块里（
BEGIN ... COMMIT）用 CTE 没问题，但不能把 CTE 当事务级变量 - 某些 BI 工具（如 Tableau）生成的 SQL 会自动包一层 CTE，如果你再手动加一层，容易触发嵌套过深或别名冲突
链式逻辑最麻烦的从来不是语法，而是环形引用检测和层级深度控制——这两项几乎没法靠数据库自动兜底，得靠业务规则提前约束数据质量。
