当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL Optimizer Trace 怎么查看索引选择原因

MySQL Optimizer Trace 怎么查看索引选择原因

来源：17golang原创 2026-09-28 17:36:41 0浏览收藏

MySQL 明明有索引，优化器却选择了全表扫描或另一条索引，单看 EXPLAIN 往往只能看到“选了什么”，看不到“为什么这样选”。这时可以在同一个连接里开启 Optimizer Trace：执行原查询，再读取 INFORMATION_SCHEMA.OPTIMIZER_TRACE，从候选访问路径、估算行数和成本判断索引落选原因。

官方地址：https://dev.mysql.com/

要点速览

Optimizer Trace 只观察当前会话，开启、执行、读取、关闭必须使用同一个连接。
先看候选索引是否可用，再比较估算行数与成本，最后确认 chosen 或 cause。
Trace 是诊断依据，不等于强制改索引；统计信息、数据分布和 SQL 写法仍要一起核对。

先用 EXPLAIN 固定要分析的查询与索引候选

建议先把线上慢 SQL 脱敏后放到测试或只读环境，用 EXPLAIN 看当前计划。下面的例子假设订单表上有 idx_status_created_at，查询希望按状态和创建时间过滤：

-- 先记录当前计划，确认实际查询与索引候选
EXPLAIN
SELECT id, user_id, created_at
FROM orders
WHERE status = 'paid'
  AND created_at >= '2026-09-01'
ORDER BY created_at DESC
LIMIT 50;

如果 key 为空，或者 key 不是预期索引，先记下 possible_keys、rows、filtered 和 Extra。Trace 的任务不是替代 EXPLAIN，而是把优化器在计划生成阶段比较过的候选展开。

MySQL Optimizer Trace 当前会话从 EXPLAIN 到执行查询再到 OPTIMIZER_TRACE 的流程说明图 — 图1：MySQL Optimizer Trace 会话流程说明图，展示开启、执行、读取和关闭的边界。

在当前会话开启 optimizer_trace 并执行原语句

不要只执行开启语句后换到另一个连接。官方流程要求在当前会话执行被追踪的语句；连接池场景尤其容易因为连接切换而读不到预期结果。

-- 只在当前诊断连接打开追踪，并给较大的 Trace 留出空间
SET optimizer_trace = 'enabled=on';
SET optimizer_trace_max_mem_size = 1000000;

-- 在同一连接执行要分析的原查询
SELECT id, user_id, created_at
FROM orders
WHERE status = 'paid'
  AND created_at >= '2026-09-01'
ORDER BY created_at DESC
LIMIT 50;

-- 读取当前会话最近的优化器记录
SELECT QUERY, TRACE, MISSING_BYTES_BEYOND_MAX_MEM_SIZE,
       INSUFFICIENT_PRIVILEGES
FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE\G

optimizer_trace_max_mem_size 过小，Trace 可能被截断；出现非零的 MISSING_BYTES_BEYOND_MAX_MEM_SIZE 时，先扩大诊断会话的上限再重跑。追踪结束后要执行：

-- 诊断完成立即关闭，避免这个连接继续积累 Trace
SET optimizer_trace = 'enabled=off';

从 OPTIMIZER_TRACE 读取候选路径与成本

TRACE 是 JSON 文本，不要从第一行直接跳到结论。先按下面的顺序搜索关键对象；不同 SQL 的节点组合会变化，但“可用性—估算—成本—选择”这条阅读路径比较稳定。

观察位置	重点字段	能回答什么
范围或访问路径分析	`index`、`ranges`、`usable`	候选索引是否能匹配谓词
行数估算	`rows`、过滤比例、扫描范围	优化器预计要读多少数据
成本比较	`cost`、`cost_for_plan`	为什么某条路径在模型中更便宜
最终决策	`chosen`、`cause`	哪条路径胜出、其他路径为何被淘汰