MySQL 查询计划选择异常时怎样读取 optimizer trace

MySQL 的 EXPLAIN 只能告诉你最后采用了哪条访问路径；如果索引明明存在，优化器却选择了全表扫描，或者连接顺序和预期不同，就需要继续看 optimizer trace。它记录优化器如何准备查询、比较候选路径以及作出选择。

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

最稳妥的做法是：在当前会话开启追踪，执行一次目标语句，从 INFORMATION_SCHEMA.OPTIMIZER_TRACE 读取 JSON，再结合 EXPLAIN 验证结论。不要把 trace 当成全局日志，也不要忽略它是否被截断。

先把 trace 限定在当前会话

optimizer trace 适合分析一次具体的计划选择，不适合长期打开收集所有请求。先在同一连接执行下面的 SQL，然后再执行要研究的查询：

-- 只在当前会话打开优化器追踪
SET optimizer_trace = 'enabled=ON';

-- 示例：把这里替换成需要分析的查询
SELECT o.id, o.total_amount
FROM orders AS o
WHERE o.customer_id = 1001
  AND o.created_at >= '2026-01-01';

-- 读取当前会话产生的追踪记录
SELECT QUERY, TRACE,
       MISSING_BYTES_BEYOND_MAX_MEM_SIZE,
       INSUFFICIENT_PRIVILEGES
FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE\G

这里的关键不是语句本身，而是连接边界。你在窗口 A 开启追踪，却在窗口 B 执行查询，窗口 A 不会凭空得到窗口 B 的 trace。分析结束后应关闭开关：

-- 分析完成后关闭当前会话的追踪
SET optimizer_trace = 'enabled=OFF';

沿着 trace 找到被放弃的候选路径

TRACE 是 JSON 文本，阅读时不要从头到尾扫字符串。先定位几个稳定区域：join_preparation 用来看查询改写和表准备，join_optimization 用来看连接与访问路径，候选项中的行数估算和代价字段则解释为什么某条路径胜出。

例如，某个索引没有被采用，不等于索引失效。trace 可能显示它的预估扫描行数更大、回表成本更高，或者排序代价使另一条路径更便宜。先把“候选存在”和“候选最终胜出”分开，再决定是否检查统计信息、索引列顺序或条件写法。

先判断 trace 是否完整，再下结论

如果 trace 被截断，只能把它当线索，不能据此断言“优化器一定因为某个成本选择了索引”。同样，trace 解释的是优化阶段的判断，不代表真实执行耗时；最后还要用 EXPLAIN、实际行数和慢查询样本交叉确认。

常见问题

optimizer trace 会记录其他连接的查询吗？

不会。它针对当前会话，开关、目标语句和读取 trace 应在同一连接中完成。

为什么 TRACE 为空？

先确认是否在开启追踪后执行了可追踪语句，再检查读取连接是否切换；涉及视图或存储程序时还要看权限字段。

optimizer trace 能替代 EXPLAIN ANALYZE 吗？

不能。trace 解释优化器如何选计划，EXPLAIN ANALYZE 更接近实际执行表现，两者回答的是不同问题。

需要一直打开 optimizer_trace 吗？

不建议。按一次问题开启、执行、读取、关闭的短会话流程使用，减少无关记录和额外内存占用。

把 trace 用作“计划选择的解释层”就够了：先锁定同一会话和同一条 SQL，再看候选路径、代价与完整性字段，最后回到 EXPLAIN 和真实运行数据做决定。