MySQL实际执行代价需通过真实指标判断：EXPLAIN的rows是预估扫描行数；performance_schema或SHOW PROFILE看真实耗时；optimizer_trace揭示优化器决策；Handler状态和锁指标反映隐藏开销。
怎么看 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 更诚实。
