TRACE字段为空并非配置失效，而是语句未进入cost-based优化阶段，常见原因包括：EXPLAIN不触发trace、语句报错跳过优化、权限不足（INSUFFICIENT_PRIVILEGES=1）、autocommit=1导致trace被覆盖、未设end_markers_in_json=ON致JSON解析失败、内存不足截断或优化器直接跳过range分析。
执行了SET optimizer_trace="enabled=on"但TRACE字段为空
这不是配置没生效，而是优化器根本没走完整决策流程。常见原因有三个：EXPLAIN SELECT不触发trace、语句报错跳过优化、或权限不足导致INSUFFICIENT_PRIVILEGES = 1。
必须执行真实SELECT（不能只EXPLAIN），且语句要能成功走到cost-based优化阶段。比如SELECT * FROM non_existent_table会直接报错，优化器连range分析都不做，TRACE就只剩空壳。
- 检查
INSUFFICIENT_PRIVILEGES字段是否为1：说明你对某张表没有SELECT权限，优化器强制清空trace - 确认语句是否真执行了：用
SELECT @@autocommit查是否为1；若为1，执行完立刻提交，trace可能被后续语句覆盖，建议先SET autocommit = 0 - 别在存储过程中盲目开trace——子查询太多时，只有最后一个子查询的trace留在表里，前面的全被覆盖
查information_schema.optimizer_trace返回空结果
不是表没数据，而是你查的不是“上一条”语句的trace。MySQL默认只保留最新一条，且SELECT * FROM information_schema.optimizer_trace查的是当前会话最后一次trace，不是你刚跑的那条。
典型误操作：开了trace → 执行A语句 → 中间又执行了B语句（哪怕只是SELECT 1）→ 再查optimizer_trace，看到的是B的trace，A的没了。
- 每次分析前加
SET optimizer_trace = "enabled=off"; SET optimizer_trace = "enabled=on";，清掉旧记录防干扰 - 想看上一条，用
SET optimizer_trace_offset = -2, optimizer_trace_limit = 1再查 - 想看连续5条（比如存储过程里5个子查询），用
SET optimizer_trace_offset = -5, optimizer_trace_limit = 5
TRACE字段是NULL或JSON解析失败
从MySQL 8.0.30起，默认end_markers_in_json = OFF，导致输出不是合法JSON——没有根大括号{}，JSON_EXTRACT(trace, '$.steps')直接返回NULL。
基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。
即使你开了optimizer_trace，也必须单独设end_markers_in_json：
- 执行目标SQL前，务必加
SET SESSION end_markers_in_json = ON - 脚本里别硬编码依赖默认值，先查
SELECT @@end_markers_in_json，为OFF就立刻设ON - 同时检查
MISSING_BYTES_BEYOND_MAX_MEM_SIZE：大于0说明JSON被截断，该条trace不可信，应丢弃
TRACE里看不到range分析或cost对比
不是trace没开全，而是优化器压根没进入cost计算环节。典型场景：全表扫描且无索引可用、或用了FORCE INDEX等hint绕过cost评估。
TRACE字段为NULL或只有{"chosen":false}这类极简结构，基本等于告诉你：“没得选，直接扫”。
- 先确认语句是否真的能走索引：用
EXPLAIN看key列是否非NULL - 检查
optimizer_trace_features是否禁用了关键模块，比如range_optimizer = off - 复杂JOIN或子查询容易触发内存限制，默认
optimizer_trace_max_mem_size = 1048576（1MB），立刻设成4194304（4MB）再试
真正卡住人的从来不是“怎么开”，而是“为什么开了却没内容”——多数时候，问题不在trace本身，而在你执行的那条语句压根没让优化器有机会做决策。
