MySQL 8.0的CTE是解决嵌套子查询失控的刚需工具：非递归CTE替代派生表提升可读性与复用性，递归CTE（需WITH RECURSIVE）严格要求锚成员与递归成员字段一致、用UNION ALL、靠WHERE控制终止，且深度默认限1000。
MySQL 8.0 的 WITH 语法不是“锦上添花”，而是解决嵌套子查询失控的刚需工具——只要你的 SQL 出现两层以上括号嵌套、或同一段聚合逻辑被复制粘贴两次以上，就该用 CTE。
非递归 CTE：替代派生表，让中间结果可读可复用
派生表写法（FROM (SELECT ...) AS t）的问题是：它必须紧贴在 FROM 子句里，主逻辑被压在最底层，想改统计口径就得从里往外扒三层；而 CTE 把计算提前、命名、暴露出来。
- 字段名不显式声明时，CTE 自动沿用子查询的列名，但一旦涉及表达式（比如
COUNT(*) AS cnt），建议显式列出列名，避免后续引用出错 - 多个 CTE 用逗号分隔，后面的 CTE 可以直接
JOIN前面的 CTE，比如先算部门均值，再算员工对比，最后关联用户信息 - CTE 不会物化，MySQL 通常会将其内联展开优化，所以性能和等价的子查询基本一致，别指望它自动缓存
- 错误示例：
WITH dept_avg AS (SELECT dept_id, AVG(salary) FROM emp) SELECT * FROM dept_avg JOIN emp ON emp.dept_id = dept_avg.dept_id;—— 这里AVG(salary)没给别名，且没GROUP BY，会报错Invalid use of group function
递归 CTE：处理树形结构必须加 WITH RECURSIVE
普通 WITH 不支持自引用，想查组织架构、菜单树、BOM 展开，必须显式写 WITH RECURSIVE，否则 MySQL 直接报错 Recursive common table expression 'xxx' must be defined with 'WITH RECURSIVE'。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 锚成员（anchor）和递归成员（recursive）的字段数量、顺序、类型必须严格一致，否则报错
Operand should contain 3 column(s)类提示 - 必须用
UNION ALL，不能用UNION—— 后者去重会破坏层级路径，还可能让递归提前终止 - 终止条件靠递归成员里的
WHERE控制，比如e.manager_id = cte.id配合e.manager_id IS NOT NULL，缺了就可能无限循环，触发ERROR 3636 (HY000): Recursive query aborted after 1001 iterations - 默认最大递归深度是 1000，超限会报错；可通过
SET SESSION cte_max_recursion_depth = 2000;临时调高，但得确认业务数据真实深度，别无脑放大
CTE 和临时表/视图的关键区别在哪
CTE 不是临时表，也不是视图，它的生命周期只绑定当前一条语句。这意味着：
- 不能在存储过程中跨语句复用同一个 CTE 名字，每条
SELECT/INSERT/UPDATE都要重新定义WITH - 不能对 CTE 执行
CREATE INDEX或ANALYZE TABLE，它没有物理存储 - 视图是持久化的，CTE 是一次性的；临时表能被多条语句读写，CTE 只属于它所在的那条 SQL
- 如果你发现 CTE 查询变慢，优先检查执行计划里是否真的用了索引 —— CTE 不改变底层表访问方式，只是语法糖
真正容易被忽略的是：CTE 的列名推导规则和字段类型隐式转换。比如在递归 CTE 中，锚成员返回 INT，递归成员却用字符串拼接生成 ID 路径（CONCAT(cte.path, '-', e.id)），会导致整个列变成 VARCHAR，后续按数字排序或比较就会出问题。这种细节不会报错，但结果会静默偏离预期。
