派生表被物化后变慢，是因为MySQL先执行子查询生成无索引的内部临时表，导致后续JOIN或过滤只能全表扫描；尤其当含窗口函数、GROUP BY、LIMIT或多UNION ALL时，5.7及更早版本必然物化，8.0默认也不下推，且物化表无主键、无索引，无法利用原表索引，多次引用或作为被驱动表时性能急剧下降。
派生表被物化后为什么变慢
派生表被物化，本质是 MySQL 先执行子查询、把结果存进一个无索引的内部临时表，再参与外层逻辑——DERIVED 类型在 EXPLAIN 中一出现，基本就等于“全表扫描已锁定”。常见表现包括：type=ALL、rows 值巨大、Extra 里带 Using temporary 或 Using filesort。
尤其当派生表来自窗口函数（如 ROW_NUMBER() OVER(...)）、GROUP BY、LIMIT 或多 UNION ALL 时，MySQL 5.7 及更早版本几乎必然物化；8.0 虽支持下推，但默认不触发，仍需手动干预。
- 物化表默认无主键、无索引，哪怕外层
ON或WHERE有强过滤条件，也无法利用原表索引 - 如果派生表被 JOIN 多次或作为被驱动表，每次匹配都要扫完整个临时结果集
-
ORDER BY在派生表里常被忽略（合并失败后），排序实际发生在物化之后，开销翻倍
如何让派生表不物化：检查合并条件是否满足
MySQL 优先尝试“合并”（merge）策略，即把子查询打平成普通 JOIN。但必须同时满足以下全部条件：
- 子查询不含
GROUP BY、DISTINCT、LIMIT、ORDER BY（外层也无排序需求） - 子查询无聚合函数（
COUNT()、SUM()、MAX()等） - 外层
FROM中只有该派生表，或仅与简单表JOIN（不能嵌套或带条件） - 整个查询涉及表数 ≤ 61（默认
optimizer_search_depth）
例如：SELECT * FROM (SELECT id, name FROM users WHERE deleted = 0) AS u WHERE u.id > 1000，若 users(deleted, id) 有复合索引，且外层无 GROUP BY，就很可能合并成功。用 EXPLAIN FORMAT=TREE 查看是否出现 -> Filter on u.id 而非 -> Materialize。
MySQL 8.0.22+ 怎么启用派生条件下推
当合并不可行（比如子查询含 GROUP BY 或窗口函数），又想避免物化开销，可启用 Derived Condition Pushdown。它不是自动生效的，必须显式提示：
- 在子查询中加优化器提示：
/*+ DERIVED_CONDITION_PUSHDOWN(dt) */，其中dt是派生表别名 - 验证是否生效：运行
EXPLAIN FORMAT=TREE，看到类似-> Filter on dt.rn的下推字样才算成功 - 注意副作用：子查询本身执行变重（比如
ORDER BY ... LIMIT 1提前执行），但整体扫描行数大幅下降，适合大结果集 + 强过滤场景
反例：SELECT * FROM (SELECT cont_number, MAX(create_time) FROM log GROUP BY cont_number) AS dt WHERE dt.cont_number = 'xxx' —— 这里 GROUP BY 阻止合并，但 cont_number 过滤可下推，加提示后，MAX() 计算只在匹配的 cont_number 上执行，而非全表分组。
实在没法合并/下推？直接换掉派生表
强行让复杂派生表“工作”，往往掩盖了语义设计问题。更干净的解法是重构：
- 用
LATERAL替代FROM (SELECT ...)：MySQL 8.0.14+ 支持，能将外层字段传入子查询，避免物化。例如把LEFT JOIN (SELECT ... FROM t2 WHERE t2.id = exe.id ORDER BY ts DESC LIMIT 1) AS main改为LEFT JOIN LATERAL (SELECT ... FROM t2 WHERE t2.id = exe.id ORDER BY ts DESC LIMIT 1) AS main - 用
EXISTS或IN替代单列去重派生表：(SELECT DISTINCT f1 FROM t2)→ 直接WHERE f1 IN (SELECT f1 FROM t2)（注意 NULL 处理） - 对分表汇总类需求（
UNION ALL日志表），改用分区表或物化视图（如 MySQL 8.0 的CREATE TABLE ... AS SELECT+ 定时刷新）
真正容易被忽略的点是：派生表慢，往往不是写法问题，而是它本就不该存在——多数时候，业务语义能用 JOIN + 条件下推更直接表达，而物化只是妥协路径。
