必须在同一会话中严格按顺序操作：先开启optimizer_trace→执行真实查询→立即查information_schema.optimizer_trace→关闭；中间任何其他语句都会覆盖trace。
为什么开了optimizer_trace却查不到TRACE内容
这不是配置错了，而是执行链断了。必须在同一个会话里严格按顺序操作：先开 trace → 再执行真实查询（EXPLAIN不触发）→ 立即查 INFORMATION_SCHEMA.OPTIMIZER_TRACE → 关闭。中间穿插任何其他语句（包括另一个 SELECT），都会覆盖上一条 trace。
常见干扰点：
-
INSUFFICIENT_PRIVILEGES = 1表示你对语句中某张表没SELECT权限，trace 会被清空 - 语句本身报错（如列不存在、表名拼错），优化器跳过完整优化阶段，
TRACE字段为空或只有极简结构 -
autocommit = 1时，SELECT执行完立刻提交，trace 可能被清掉；建议先SET autocommit = 0，查完再ROLLBACK
怎么设参数才能看到完整的索引评估过程
默认内存限制（optimizer_trace_max_mem_size = 1048576）对稍复杂的查询根本不够——联合索引、多表 JOIN 或带子查询的语句，很容易触发 MISSING_BYTES_BEYOND_MAX_MEM_SIZE > 0，关键字段如 potential_range_indices 直接被砍掉。
必须手动调参：
- 执行
SET SESSION optimizer_trace_max_mem_size = 4194304（即 4MB） - 务必加
end_markers_in_json = ON，否则 JSON 里没有结构分隔符，读起来像一整块乱码 - 开启命令要写成一条：
SET SESSION optimizer_trace = "enabled=on", end_markers_in_json = ON, optimizer_trace_max_mem_size = 4194304
怎么看TRACE里真正决定索引选择的关键字段
别只扫顶层字段。重点翻 steps 数组里的嵌套结构，尤其是 join_optimization → range_analysis → analyzing_range_alternatives 节点下的 potential_range_indices 数组。
每个候选索引包含：
-
index：索引名 -
ranges：实际生成的范围条件（注意隐式类型转换是否让条件失效） -
rows：估算扫描行数（不是真实值，依赖统计信息准确性） -
cost：优化器真正用来决策的总代价（含回表、IO、CPU 等加权）
典型陷阱：idx_create_time_status 的 cost 是 120000，而全表扫描才 98000 —— 这说明“走索引 + 回表”被判定为更贵，原因常是 rows 估算过大（统计信息陈旧）或 row_evaluate_cost 参数偏高。
如何避免误读TRACE中的“被放弃计划”
considered_execution_plans 列出所有候选计划及其 cost，但别只看数字大小。要对比“被选中”和“被放弃”的具体差异项：
- 检查
ref_optimizer_key_uses块里using_index是否为false，若为false，说明即使走了索引也得回表，得往前翻condition_processing看 WHERE 是否被重写、是否触发隐式转换 - 如果看到
"index": "PRIMARY"但"rows": 999999，大概率是缺合适的复合索引，而非主键索引本身有问题 -
table_scan的cost比索引低，优先检查rows估算是否严重偏离实际（用ANALYZE TABLE更新统计信息再试）
最易忽略的是：Optimizer Trace 记录的是“那一刻”的决策依据，它反映的是当前统计信息、参数配置、SQL 写法共同作用的结果。换一个 WHERE 值、更新一次统计、改一行 ORDER BY，整个 cost 排序都可能变。别把它当静态快照，要当成一次动态推演来看。
