key表示实际选用的索引名，仅说明“选了哪个索引”而非“用得对”；rows是优化器预估扫描行数，反映索引过滤效率，值接近全表行数常意味索引失效。
EXPLAIN 看懂 key 和 rows 的真实含义
MySQL 不会直接告诉你“这个索引花了多少毫秒”，而是通过 EXPLAIN 暴露执行计划里的关键线索。key 字段显示实际用到的索引名，但很多人误以为只要非 NULL 就代表高效——其实它只说明“选了哪个索引”，不等于“用得对”。rows 是优化器预估的扫描行数，不是返回行数，也不是磁盘 IO 次数，但它最能反映索引过滤效率。
常见错误现象：rows 接近全表行数，但 key 显示用了索引，说明索引区分度极低（比如在 is_deleted TINYINT 上建索引），或者查询条件没触发最左前缀（WHERE status = ? AND created_at > ? 却只在 (created_at) 上建索引）。
- 用
EXPLAIN FORMAT=JSON查看filtered字段，它表示该条件下行被保留的概率（0–100），低于 10 常意味着索引失效风险高 -
type为range或ref通常合理；ALL或index要警惕，尤其当rows过大时 - 避免在
WHERE中对索引字段做函数操作，如WHERE YEAR(created_at) = 2024会让created_at索引完全失效
用 sys.schema_index_statistics 查真实索引使用频次
优化器预估可能严重偏离实际。有些索引常年没人用，却拖慢写入性能；有些查询明明走了索引，但因回表开销大，整体反而更慢。MySQL 8.0+ 的 sys 库提供了运行时统计视角。
使用场景：上线后想确认某条慢查询是否真靠索引提速了，或清理长期闲置的冗余索引。
- 查某个索引被用了多少次：
SELECT * FROM sys.schema_index_statistics WHERE table_name = 'orders' AND index_name = 'idx_user_id_status' - 注意
reads是逻辑读次数，不是物理 IO；如果reads极低但select_latency很高，大概率是回表或排序导致瓶颈 - 该视图不记录历史，重启 MySQL 后归零；若需长期追踪，得配合定期快照或开启 Performance Schema 的
events_statements_history_long
optimizer_trace 揭露为什么没选你期待的索引
当你写了索引、EXPLAIN 却显示 key: NULL，别急着改 SQL——先打开优化器追踪，看它到底评估了哪些索引、成本怎么算的。这是定位“索引被忽略”类问题的唯一可靠方式。
参数差异：optimizer_trace 默认关闭，需手动开启；它只对当前 session 生效，且仅记录最近一条语句的完整决策链。
- 开启并执行查询：
SET optimizer_trace="enabled=on"; SELECT ...; SELECT * FROM information_schema.optimizer_trace; - 重点看
steps数组里considered_access_paths下各索引的cost和chosen字段，对比你预期索引的成本值 - 常见原因：统计信息过期（
ANALYZE TABLE可修复）、索引列存在大量 NULL 值导致基数误判、或优化器认为全表扫描比走索引再回表更快（尤其当SELECT *+ 高偏移分页时）
写入开销常被忽略：每个索引都是双倍写压力
评估索引开销不能只盯查询。每新增一个二级索引，INSERT/UPDATE/DELETE 都要额外维护 B+ 树结构，且事务日志（binlog + redo log）体积同步增大。线上表写入 QPS 高时，这会成为隐性瓶颈。
性能影响：单条 INSERT 多索引的耗时不是线性叠加，而是受最慢那个索引的树分裂、页分裂影响；尤其在 SSD 上随机写放大明显。
- 用
SHOW INDEX FROM table_name查索引列数和类型，优先合并单列索引为复合索引（如idx_a+idx_a_b→ 保留idx_a_b即可） - 对写多读少的表（如日志、埋点），索引宁缺毋滥；必要时用覆盖索引减少回表，但别为了“看起来快”堆砌过多字段
- 监控
Innodb_buffer_pool_pages_dirty和Innodb_log_waits，若二者持续升高，可能正被索引写入拖累刷脏页和日志提交
索引不是越多越好，也不是越“命中”越好。真正难的是在查询加速和写入成本之间找到那个动态平衡点——而这个点，永远藏在 rows、filtered、reads 和 cost 的具体数值里，不在任何经验法则中。
