必须在同会话中按顺序执行set optimizer_trace='enabled=on'、目标sql、立即查information_schema.optimizer_trace，且需调大optimizer_trace_max_mem_size、关闭autocommit、清旧trace，否则trace为空或被覆盖。
为什么开了optimizer_trace却查不到TRACE字段
不是权限或配置错，而是触发条件没满足：只有**真实执行的SELECT/UPDATE/DELETE语句**才会生成trace，EXPLAIN、语法错误、权限不足（INSUFFICIENT_PRIVILEGES = 1）、或autocommit=1下SELECT执行完立刻提交，都会导致TRACE为空或只有空壳。必须严格在同一个会话里按顺序操作：
– 先执行SET optimizer_trace = 'enabled=on', end_markers_in_json=on
– 再执行目标SQL（比如SELECT * FROM orders WHERE user_id = 100）
– 立刻执行SELECT * FROM information_schema.optimizer_trace\G
延迟查询可能已被后续语句覆盖，TRACE字段只保留当前会话最后一条有效语句的结果。
如何避免JSON被截断或只看到最后一条
optimizer_trace_max_mem_size默认仅1MB，复杂JOIN或子查询极易触发MISSING_BYTES_BEYOND_MAX_MEM_SIZE > 0，关键路径被砍掉；同时默认只存1条，多语句会互相覆盖。
– 执行前先调大内存：SET optimizer_trace_max_mem_size = 4194304（4MB）
– 查上一条trace：SET optimizer_trace_offset = -2, optimizer_trace_limit = 1，再查视图
– 查连续5条（如存储过程内多个子查询）：SET optimizer_trace_offset = -5, optimizer_trace_limit = 5
– 每次分析前加SET optimizer_trace = 'enabled=off'; SET optimizer_trace = 'enabled=on';清旧记录，防干扰
TRACE里真正该盯住的三个cost字段
别只扫顶层total_cost，它藏在深层嵌套里，真正影响决策的是相对值：
– read_cost：引擎层读取成本（索引查找、回表、IO预估）
– eval_cost：Server层WHERE条件判断成本（行数 × 每行开销）
– prefix_cost：多表JOIN中到当前表为止的累计成本，比total_cost更能反映该表“贡献”
这些值单位是“随机IO次数”，不是毫秒；同一语句不同plan之间可比，跨语句不可比。路径通常是：steps → join_optimization → considered_execution_plans → [0] → cost
从steps里快速定位索引选择失败原因
重点翻steps数组里的join_optimization块：
– condition_processing看WHERE是否被重写（比如隐式类型转换导致索引失效）
– range_analysis → analyzing_range_alternatives里若显示"index": "PRIMARY"但"rows": 999999，说明优化器认为全表扫比走主键范围更快——大概率缺复合索引
– ref_optimizer_key_uses里"using_index": false，得回溯前面condition_processing确认是否因函数包裹、类型不匹配导致索引失效
– considered_execution_plans列出所有候选计划及cost，对比“被选中”和“被放弃”的cost差值，差得远就说明优化器判断有依据，差得近就得怀疑统计信息过期或参数设置问题
最常被忽略的是：每次分析前没清旧trace、没关autocommit、没立刻查结果、没调内存上限——四个动作漏一个，TRACE就大概率废掉。
