MySQL optimizer_trace 查看范围优化决策路径的配置方法

MySQL 执行计划只告诉你最终选了什么，想知道范围条件为什么被接受、放弃或改成全表扫描，可以在同一个会话中打开 optimizer_trace，再读取 INFORMATION_SCHEMA.OPTIMIZER_TRACE。它适合解释一次具体查询的优化决策，不等同于线上性能测试。

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

先记住结论：只在目标连接开启追踪；用 optimizer_trace_features 保留 range_optimizer；读取 trace 后立刻关闭。若结果显示 MISSING_BYTES_BEYOND_MAX_MEM_SIZE，先把它当作“不完整证据”，不要直接据此改索引。

1. 只在目标会话打开追踪

optimizer trace 是会话范围的。先设置开关，再限制追踪内容，最后执行要解释的 SELECT。下面的示例只关注范围优化，便于从 JSON 中定位关键节点。

-- 只影响当前连接，避免把其他会话的查询混进来
SET SESSION optimizer_trace = 'enabled=on';

-- 保留范围优化记录，减少无关优化阶段的噪声
SET SESSION optimizer_trace_features = 'greedy_search=off,range_optimizer=on,dynamic_range=on,repeated_subselect=off';

-- 让 trace 有足够空间保存一次复杂查询的决策
SET SESSION optimizer_trace_max_mem_size = 1048576;

-- 执行需要解释的目标查询
SELECT id, created_at
FROM orders
WHERE customer_id = 42 AND created_at >= '2026-01-01';

2. 从 OPTIMIZER_TRACE 读取范围节点

追踪结果只属于当前连接。先看查询文本和是否缺字节，再把 TRACE 当 JSON 展开。不同 SQL 的节点层级可能不同，因此不要依赖固定数组下标；应搜索 range_optimizer、analyzing_range_alternatives 或 chosen_range_access_summary 这些语义节点。

-- 先确认正在读取当前会话最近生成的 trace
SELECT QUERY,
       MISSING_BYTES_BEYOND_MAX_MEM_SIZE,
       TRACE
FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE
ORDER BY QUERY
LIMIT 1;

-- 关闭追踪，避免后续无关查询继续写入 trace
SET SESSION optimizer_trace = 'enabled=off';

QUERY 用来确认样本是不是目标语句，TRACE 用来解释决策，MISSING_BYTES_BEYOND_MAX_MEM_SIZE 则用来判断内容是否因内存上限而不完整。遇到多个样本时，配合 optimizer_trace_limit 与 optimizer_trace_offset 控制读取窗口。

3. 用三类信号判断范围为什么没被采用

先看有没有范围候选，再看候选的成本与预估行数，最后看 chosen summary。没有候选通常意味着谓词无法转成可用的索引范围；有候选但未选择，常见原因是成本估算认为扫描代价更高；如果 trace 标明内存不足，则应先增大当前会话的 trace 或范围优化内存，再重新采样。

4. 参数边界与排查清单

optimizer_trace_max_mem_size 控制已保存 trace 的累计空间，range_optimizer_max_mem_size 则影响范围优化本身可用的内存，两者不是同一个旋钮。调大参数前先在测试会话复现，并保留原值；调参后重新执行同一 SQL，比较候选是否变化。trace 只能解释优化器当时的判断，不能代替真实数据分布下的执行耗时。

1. 确认查询文本与连接一致，避免读取错会话。
2. 检查 MISSING_BYTES_BEYOND_MAX_MEM_SIZE 是否为零。
3. 把 trace 的候选、估算行数与 EXPLAIN 并排记录。
4. 完成一次采样就关闭追踪，不把调试开关留在连接池初始化里。

常见问题

为什么 OPTIMIZER_TRACE 为空？通常是没有在当前会话开启追踪、查询尚未执行，或读取发生在另一条连接上。重新在同一连接完成“开启—执行—读取”三步。

trace 能直接证明索引一定更快吗？不能。它记录优化器的估算与选择过程；最终效果仍要结合实际数据、执行耗时和资源指标判断。