怎么看 MySQL 实际执行的查询代价
MySQL 本身不直接暴露“查询代价”的数值（比如 12.7 cost 这种），
EXPLAIN输出里的
cost列仅在启用
optimizer_trace或使用
EXPLAIN FORMAT=JSON时才可能间接体现，且是优化器预估值，不是真实开销。真正可观察、可对比的代价，得看实际执行行为：
EXPLAIN中的
rows值——优化器预估扫描行数，越接近真实扫描量，预估越可信；明显偏高通常意味着统计信息过期或缺少有效索引 开启
profiling（已弃用）或更推荐用
performance_schema查
events_statements_history_long，看
TIMER_WAIT（纳秒级真实执行耗时）和
LOCK_TIME用
SHOW PROFILE FOR QUERY N（需先
SET profiling = 1）看各阶段耗时分布，比如
Copying to tmp table或
Sorting result占比高，说明临时表或排序成了瓶颈
为什么 EXPLAIN
的 key_len
比预期小
key_len显示的是 MySQL 实际用到的索引字节数，不是定义长度。它小，往往意味着索引没被充分利用，常见原因有： 索引列存在
NULL，且查询条件是
IS NULL或未加
NOT NULL约束，导致无法使用最左前缀匹配 查询条件用了函数或表达式，如
WHERE YEAR(created_at) = 2024，即使
created_at有索引，
key_len也会是 0 联合索引中，中间某列用了范围查询（
>,
BETWEEN,
LIKE 'abc%'），后续列就失效，
key_len只计算到范围列为止 字符集不同导致隐式转换，比如
utf8mb4列与
utf8字符串比较，索引可能部分失效
如何用 optimizer_trace
看优化器真实决策过程
这是唯一能看清 MySQL “怎么算出这个执行计划”的方式，但默认关闭，且有性能开销，只应在调试时临时启用：
执行SET optimizer_trace="enabled=on", end_markers_in_json=on;运行目标
SELECT查询 查
SELECT * FROM information_schema.OPTIMIZER_TRACE;，重点关注
steps数组里的
considered_execution_plans和
analyzing_range_alternatives注意：每条 trace 只保留最后一次查询，且不会记录全表扫描以外的备选方案（除非强制
USE INDEX） 别在生产环境长期开启——trace 本身会增加解析和记录开销，尤其复杂查询可能生成 MB 级 JSON
真实代价常被忽略的三个隐藏项
很多人只盯着
EXPLAIN的
rows和响应时间，但以下三项在高并发或大数据量下影响巨大：
Handler_read_next/
Handler_read_rnd_next：从
SHOW STATUS LIKE 'Handler%'查，前者高说明索引扫描效率低，后者高基本等于频繁回表，是二级索引 +
SELECT *的典型信号 临时表类型：若
Created_tmp_disk_tables持续增长，说明
sort_buffer_size或
tmp_table_size不足，磁盘临时表比内存表慢 1–2 个数量级 锁等待：即使查询快，若
Innodb_row_lock_time_avg超过 10ms，大概率存在热点行锁争用，这时优化 SQL 不如拆分更新粒度或调整事务边界
代价分析不是单看一条语句跑多快，而是把执行路径、资源消耗、并发干扰全串起来看——尤其是
Handler状态和锁指标，它们比
EXPLAIN更诚实。
