Optimizer Trace 适合解决哪些执行计划疑问

Optimizer Trace 最适合回答的不是“这条 SQL 实际跑了几秒”，而是“优化器在生成执行计划时考虑了什么，又为什么放弃某条访问路径”。当 EXPLAIN 只告诉你最终选择了哪个索引、连接顺序看起来不合理，或者某个范围条件没有走预期索引时，Trace 能把中间决策补出来。

官方文档地址：https://dev.mysql.com/doc/refman/8.4/en/optimizer-tracing.html

一句话判断：用 Optimizer Trace 解释“计划为什么这样选”，用运行时观测解释“计划实际跑得怎么样”。它是当前会话级的优化过程记录，不是慢查询日志，也不是实际行数采样器。

• 适合定位索引、范围访问、连接顺序和条件改写的决策依据。
• 适合解释候选方案被拒绝的原因，以及估算值从哪里开始偏离。
• 不适合单独证明真实耗时、锁等待、磁盘 IO 或实际返回行数。

先判断 Optimizer Trace 能回答哪类疑问

我通常先把疑问分成两层。第一层是优化阶段：谓词有没有被改写、哪些索引被列入候选、表的连接顺序如何比较、成本估算为何支持最终方案。这一层是 Trace 的强项。第二层是执行阶段：实际扫描了多少行、是否发生回表、等待锁多久、缓存命中是否稳定。这些要交给 EXPLAIN ANALYZE、性能监控和慢查询样本。

因此，“明明有联合索引却没选”值得开 Trace；“昨天同一计划只要 20 毫秒，今天变成 2 秒”则不能只看 Trace。前者先查选择过程，后者还要核对数据分布、统计信息、并发和运行时资源。

用当前会话抓取一次完整 Trace

官方推荐的路径很短：在当前会话开启追踪，执行目标语句，再读取 INFORMATION_SCHEMA.OPTIMIZER_TRACE，完成后关闭追踪。不要在一个连接里开启、换到连接池的另一个连接执行；Trace 只对执行它的当前会话可见。

-- 只在当前会话打开追踪，避免影响其他连接
SET optimizer_trace = 'enabled=on';
-- 给较大的复杂查询留下足够的 Trace 存储空间
SET optimizer_trace_max_mem_size = 1048576;

-- 把这里替换成需要解释执行计划的 SELECT
SELECT o.id, o.customer_id
FROM orders AS o
WHERE o.customer_id = 1001
  AND o.created_at >= '2026-01-01'
ORDER BY o.created_at DESC
LIMIT 20;

-- 查询当前会话最近保存的优化过程记录
SELECT QUERY, TRACE, MISSING_BYTES_BEYOND_MAX_MEM_SIZE,
       INSUFFICIENT_PRIVILEGES
FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE\G

-- 诊断完成后关闭追踪
SET optimizer_trace = 'enabled=off';

这里的 QUERY 用来确认读到的确实是目标语句，TRACE 是 JSON 形式的优化过程。若一次连接连续分析多条 SQL，先看 QUERY 再看 TRACE，不要把上一条语句的记录误当成当前样本。

按决策节点读取访问路径与成本

Trace 很长时不要从头到尾逐字符阅读，可以按四个问题定位。先看条件处理节点，确认常量折叠、谓词下推或条件简化是否发生；再看行数估算，观察表扫描、范围访问和不同索引候选的估算记录；随后看候选执行计划，比较访问方式、连接顺序和成本；最后看选中的计划，把它与 EXPLAIN 的最终摘要对应起来。

要特别注意“估算偏差”这个信号：Trace 说明优化器当时相信什么，不等于它相信的数字正确。若估算行数明显偏小，下一步应更新统计信息、检查数据分布和谓词选择性，而不是立刻强制索引。

把 Trace 结论变成可执行排查清单

第一步先确认追踪完整。MISSING_BYTES_BEYOND_MAX_MEM_SIZE 非零时，当前记录可能在达到内存上限后停止扩展；先提高会话级 optimizer_trace_max_mem_size，再比较完整记录。第二步确认权限边界。若 INSUFFICIENT_PRIVILEGES 为 1，涉及定义者安全视图或存储程序时，空 Trace 不代表优化器没有决策。

第三步只针对 Trace 明确指出的分歧行动：估算行数不准，先处理统计信息；候选路径因谓词不可用被排除，先检查表达式和隐式类型转换；连接顺序成本更低，先验证数据分布，不要仅凭直觉改写 SQL。第四步补运行时证据，用 EXPLAIN ANALYZE 或慢查询样本核对实际行数和耗时。

我更愿意把 Trace 当作一次“决策复盘”：它告诉你优化器的视角，帮助缩小排查范围；真正上线前的判断，还要把估算、实际执行和业务数据变化放在同一张证据表里。

常见误区与边界

Trace 能替代 EXPLAIN 吗？不能。EXPLAIN 适合快速查看最终计划，Trace 适合追问选择过程，两者应配合使用。

Trace 能证明索引一定更快吗？不能。它记录优化器的选择依据，不提供完整的锁等待、IO 和并发表现；最终仍需运行时测量。

为什么换一个客户端看不到记录？因为追踪绑定执行语句的当前会话。把开启、执行和读取放在同一个连接中，才能得到对应结果。