MySQL 8.0 中 CTE 默认不强制物化，优化器根据成本估算决定内联展开或物化为临时表；非递归CTE可被MATERIALIZED提示显式物化，递归CTE则固定由迭代引擎执行，绕过代价优化。
MySQL 8.0 中 CTE 不是物化视图，优化器可能内联或重写
MySQL 8.0 的 CTE 默认**不强制物化**——它更像一个带名字的子查询，优化器会根据成本估算决定是否实际生成临时结果集。这意味着你写的 WITH cte AS (SELECT ...) 可能在执行计划里完全消失，被直接展开进主查询；也可能被物化为临时表，取决于字段、过滤条件、JOIN 次数等。别默认“CTE = 缓存”，这是最常被误解的一点。
常见现象：EXPLAIN 显示没有 cte 相关行，只有原始表扫描；或者出现 DERIVED 类型但没标出 CTE 名。这说明优化器已内联处理。
- 显式要求物化：加
MATERIALIZED提示（MySQL 8.0.23+），如WITH cte AS MATERIALIZED (SELECT ...)，否则不保证物化 - 非递归 CTE 若只被引用一次，大概率被内联；若被 JOIN 多次或出现在多个
UNION分支中，更可能被物化 - 物化后默认无索引，除非你用
CREATE TEMPORARY TABLE手动建索引——CTE 本身不支持INDEX定义
递归 CTE 固定为迭代执行，不走传统优化器路径
递归 CTE（WITH RECURSIVE）完全绕过标准的基于代价的优化流程。它被解析器识别后，直接交由专用的**迭代执行引擎**处理：先跑锚成员得 R0，再用 R0 驱动递归成员得 R1，以此类推，直到输出为空。这个过程无法被 JOIN 重排序、不能下推 WHERE 到递归体内部，也不参与索引合并优化。
所以你看不到递归部分的 type=ref 或 key=xxx，EXPLAIN 对递归成员基本无效——它只告诉你“这是递归步骤”，不告诉你怎么查。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 真正影响性能的是：锚成员输出大小、递归成员中
JOIN的驱动方向、关联字段是否有索引 -
ORDER BY、LIMIT、GROUP BY禁止出现在递归成员中，否则直接报错ERROR 3641 - 想控制深度？靠外层
WHERE level 过滤，不是靠优化器剪枝
CTE 字段引用影响执行计划稳定性
CTE 中的列如果来自表达式（比如 UPPER(name)、COALESCE(email, 'N/A')），且该列又被主查询用于 JOIN 或 WHERE，优化器可能无法复用底层表索引，导致全表扫描。尤其当 CTE 被多次引用时，相同表达式会被重复计算，而不会自动提取为公共子表达式（CSE）。
例如：WITH user_data AS (SELECT id, UPPER(email) AS uemail FROM users)，后续 JOIN ON uemail = ? 就无法走 users.email 上的索引，除非你额外建函数索引（MySQL 8.0.13+ 支持）。
- 尽量在 CTE 内使用原始字段，把转换逻辑移到外层 SELECT
- 若必须用表达式字段做连接，确认目标列已建对应函数索引，如
CREATE INDEX idx_upper_email ON users ((UPPER(email))) -
SELECT *在 CTE 中极危险：表结构新增字段会导致递归 CTE 报错ERROR 1252，因为锚成员和递归成员字段数对不上
物化时机与内存/磁盘切换由 tmp_table_size 和数据量共同决定
当优化器决定物化 CTE（比如多次引用或含聚合），它会先尝试用内存临时表（MEMORY 引擎）。一旦中间结果超出 tmp_table_size 或 max_heap_table_size 中较小者，就会自动落盘为 MyISAM 或 InnoDB 临时表——这个切换不可控，且落盘后性能断崖下跌。
典型症状：小数据量快，一到几万行就明显变慢；SHOW STATUS LIKE 'Created_tmp%' 显示 Created_tmp_disk_tables 激增。
- 检查当前设置：
SELECT @@tmp_table_size, @@max_heap_table_size; - 临时调大（会话级）：
SET SESSION tmp_table_size = 268435456;（256MB） - 比调参更可靠的做法：在 CTE 前加强过滤（如
WHERE created_at >= ...），从源头减少物化数据量
