CTE不是物化表，执行时按需内联展开；非递归CTE由优化器决定是否复用，可能多次执行同一子查询，递归CTE则迭代计算，需显式终止条件与索引支持。
CTE 不是物化表，执行时按需“展开”
MySQL 8.0 的 CTE 在底层不生成临时物理表，也不缓存中间结果——它更像一个语法糖式的“宏展开”。优化器会在解析阶段把 WITH 定义的 CTE 内联进主查询，等价于把 CTE 的子查询原样替换到所有引用它的位置（类似视图展开），再做整体优化。这意味着：cte_name 出现 3 次，对应子查询就可能被执行 3 次（除非被优化器识别为可复用）。
常见错误现象：写了一个耗时的聚合 CTE，然后在 SELECT 和 WHERE 中各引用一次，实际执行计划里看到该子查询跑了两次。
- 非递归 CTE 无强制物化机制；是否复用取决于优化器判断，不可预期
-
EXPLAIN FORMAT=TREE能清晰看到 CTE 被“扁平化”后的执行树结构 - 若想强制物化（避免重复计算），需显式用
CREATE TEMPORARY TABLE+INSERT ... SELECT替代
递归 CTE 的执行是迭代式求值，不是一次性展开
WITH RECURSIVE 是唯一真正“运行时构造”的 CTE 类型。它不会被展开，而是由 MySQL 执行引擎按轮次迭代计算：先跑锚成员（anchor），再以该结果为输入跑递归成员（recursive），合并后作为下一轮输入，直到递归成员返回空集或达到最大迭代次数（默认 cte_max_recursion_depth=1000）。
容易踩的坑：
- 忘记加
WHERE终止条件 → 触发Recursive query aborted after 1001 iterations错误 - 递归部分用了
UNION而非UNION ALL→ 去重开销大，且可能因隐式排序中断迭代逻辑 - 递归查询中用了
GROUP BY、ORDER BY或窗口函数 → 直接报错，MySQL 明确禁止
多 CTE 定义之间存在依赖顺序，但无执行顺序保证
当写多个 CTE（如 WITH cte1 AS (...), cte2 AS (SELECT ... FROM cte1)），MySQL 要求定义顺序必须满足引用依赖（cte2 可引用 cte1，反之不行），但这只是语法检查层面的约束。底层执行时，优化器仍可能重排实际执行顺序——尤其是当 cte1 和 cte2 无数据依赖时。
使用场景注意：
- 若
cte2真依赖cte1的结果（比如做 JOIN），MySQL 会确保先算cte1；但若只是名字引用而无真实数据流（如cte2也独立查同一张表），优化器可能并行或重排 - 不要假设 CTE 定义顺序 = 执行顺序，尤其在含复杂过滤或 LIMIT 时，行为更不确定
-
EXPLAIN输出里看不到 CTE 名字，只看到最终展开后的表和连接顺序
CTE 对执行计划的影响常被低估
CTE 的主要价值是提升可读性，但它对执行计划没有“优化承诺”。有时强行拆成 CTE 反而干扰优化器选择更优路径，比如把本可走索引的条件塞进 CTE 后，主查询再过滤，导致全表扫描。
性能关键点：
- CTE 内部的
WHERE条件越早过滤掉数据，越有利于整体性能；延迟到主查询再 filter 可能已丢失索引优势 - 递归 CTE 的层级深度直接影响迭代次数，
level字段若未参与索引或 WHERE，深度过大时性能断崖下跌 - CTE 中引用的表若没合适索引（特别是递归 JOIN 的 ON 字段），每次迭代都可能触发全表扫描
最易被忽略的是：CTE 的列别名和类型推导会影响后续运算——比如递归部分用 CAST(... AS CHAR) 显式指定长度，比隐式转换更稳定，避免因类型不一致导致隐式转换或截断。
