MySQL 派生表为什么影响临时表：derived_merge 与窗口函数的执行边界

线上订单报表突然多出一张内部临时表时，先别急着把 derived_merge 关掉。MySQL 对 FROM 子查询有两条路：能合并就把派生表并入外层查询，不能合并就先物化成内部临时表；一旦派生表包含窗口函数，合并边界会被明确卡住。

判断关键不在“有没有子查询”，而在派生表是否满足合并条件。窗口函数会让该派生表始终物化，应该围绕物化后的行数、过滤位置和排序开销做优化。

先用订单排名查询还原两条执行路径

假设 orders 表有 user_id、created_at、amount 三个字段。需求是找出每个用户最近三笔订单：

SELECT user_id, order_id, created_at, amount
FROM (
  SELECT user_id, order_id, created_at, amount,
         ROW_NUMBER() OVER (
           PARTITION BY user_id ORDER BY created_at DESC
         ) AS rn
  FROM orders
) AS ranked_orders
WHERE rn 

这里的 ranked_orders 不是普通的字段投影，它先要完成窗口计算，外层才能读取 rn。MySQL 官方手册把派生表的处理概括为合并到外层查询块，或物化到内部临时表；窗口函数会让派生表合并被禁用。

这也是第一个容易误判的地方：查询里出现 FROM (SELECT ...)，不等于一定产生临时表；但出现 ROW_NUMBER() 后，物化就成为这段查询的执行边界。

derived_merge 能合并什么，不能合并什么

derived_merge 是优化器开关，不是“删除派生表”的强制命令。普通的字段投影、没有聚合和窗口函数的派生表，往往可以被并入外层查询，让条件和索引选择在更大的查询块里一起判断：

SELECT order_id, amount
FROM (
  SELECT order_id, amount
  FROM orders
) AS recent_orders
WHERE amount > 500;

而下面这些情况会让合并受限，窗口函数只是其中最容易在排名报表里遇到的一种：

• 派生表需要窗口计算，外层必须读取计算后的窗口列；
• 派生表含有会改变行粒度的聚合或 DISTINCT；
• 派生表使用 GROUP BY、HAVING、LIMIT 等会改变结果边界的语义。

可以用会话级设置做对照实验，但不要把实验开关直接带进生产：

SET SESSION optimizer_switch = 'derived_merge=on';
EXPLAIN FORMAT=TREE
SELECT order_id, amount
FROM (SELECT order_id, amount FROM orders) AS recent_orders
WHERE amount > 500;

观察重点是派生表是否消失在树形计划中，以及外层 amount > 500 是否已经参与底层访问路径。

过滤条件为什么不能随意提前

对排名查询来说，rn 必须在窗口值算出来之后判断。若把它想象成普通的 WHERE 条件并提前压到 orders，就可能改变每个用户参与排名的行集合。

没有窗口函数时，MySQL 支持派生表条件下推的场景更多；有窗口函数时，优化器不能把会影响窗口结果的外层条件随意塞回窗口计算之前。实际排查时应区分两件事：

慢了以后，先缩小窗口输入再谈开关

排名查询慢，优先做语义不变的缩减：把确定不会参与报表的时间范围、租户或订单状态放进窗口派生表内部，让 ROW_NUMBER() 面对更小的输入集合；但必须确认这些条件不会改变业务要求的排名范围。

SELECT user_id, order_id, created_at, amount
FROM (
  SELECT user_id, order_id, created_at, amount,
         ROW_NUMBER() OVER (
           PARTITION BY user_id ORDER BY created_at DESC
         ) AS rn
  FROM orders
  WHERE tenant_id = 7
    AND created_at >= '2026-08-01'
) AS ranked_orders
WHERE rn 

这里的收益来自减少窗口输入，不是强行让派生表合并。若业务要的是“全历史订单中的最近三笔”，就不能擅自添加时间条件；这个结果先别下结论，先确认报表定义。

常见问题

关闭 derived_merge 能解决所有派生表问题吗？

不能。它只改变满足合并条件的派生表策略，窗口函数导致的物化边界不会因为开关而消失。

物化一定比合并慢吗？

不一定。物化可能让复杂子查询只计算一次，也可能因为中间结果太大而增加临时表开销，必须结合执行计划和数据量判断。

为什么不能把 rn 条件直接写进窗口子查询的 WHERE？

因为 rn 是窗口计算产生的结果列，计算前不存在；把条件提前会改变排名输入，语义也就变了。

线上如何验证 derived_merge 的影响？

先在同一数据快照上用 EXPLAIN FORMAT=TREE 对照，再做小流量或只读环境实测，不要直接修改全局 optimizer_switch。

把执行边界留在可验证的位置

派生表是否合并，取决于查询语义能否保持；窗口函数让这个边界更清晰。面对慢查询时，先用执行计划确认物化位置，再缩小合法的窗口输入，最后才评估会话级优化器设置。这样改动能对应到具体节点，也方便回滚。