key非空但rows很大，说明mysql虽走了索引，但实际扫描行数多，反映索引利用效率低，常见于范围查询过宽、区分度低或隐式类型转换；rows是优化器预估，常因统计信息不准或数据倾斜而严重低估。
Explain 显示 key 非空但 rows 很大，说明什么
这表示 MySQL 确实走了索引，但执行器实际扫描了大量索引记录（甚至回表记录），不是“用没用索引”的问题，而是“用了多少”的问题。rows 是优化器预估的扫描行数，它高意味着即使走索引，也要遍历大量键值——比如范围查询过宽、索引区分度低、或存在隐式类型转换导致索引截断。
type 是 range 或 index 时，rows 常被严重低估
优化器对范围扫描的行数估算依赖统计信息（如 cardinality）和简单分布假设，遇到数据倾斜、长尾分布或复合索引中前导列过滤弱时，rows 可能比真实扫描数小一个数量级。例如：
SELECT * FROM orders WHERE status IN ('pending', 'processing') AND created_at > '2024-01-01';
若 status 只有 3 个值且分布极不均，而 created_at 索引选择性又随时间衰减，优化器可能误判为“只扫几万行”，实际执行扫了几百万。
- 用
SHOW INDEX FROM table_name查看Cardinality是否合理（尤其对比表总行数） - 执行
ANALYZE TABLE table_name强制更新统计信息，再看EXPLAIN的rows是否变化 - 对
IN列表超过 5 个值，或含函数/表达式的条件，优化器常放弃精确估算，直接按启发式值（如 10% 表行数）估算
真正慢的根源常在执行器层：回表、临时表、文件排序
EXPLAIN 不显示这些开销，但它们才是耗时主体。比如：
-
Extra出现Using where; Using index：只查索引覆盖字段，快 -
Extra出现Using where; Using index condition：ICP 下推部分条件到存储引擎，减少回表，仍需关注rows -
Extra出现Using filesort或Using temporary：已脱离索引能力，必然慢——哪怕key显示用了索引 - 回表次数 =
rows× 每行需读主键的次数；若rows=500000且未覆盖索引，就是 50 万次随机主键查找，IO 成瓶颈
验证真实扫描量：用 optimizer_trace 或 performance_schema
EXPLAIN 是预估，要看真实行为：
- 开启
SET optimizer_trace="enabled=on";，执行 SQL 后查SELECT * FROM information_schema.OPTIMIZER_TRACE，重点关注rows_estimation和execution_plan中的rows_read - 查
performance_schema.events_statements_history_long，过滤该 SQL 的LOCK_TIME、ROWS_AFFECTED、ROWS_SENT，对比ROWS_EXAMINED—— 这个值才是执行器真正读的行数 - 若
ROWS_EXAMINED远大于rows，说明优化器误判；若接近但依然慢，说明单行处理成本高（如大字段、JSON 解析、UDF）
索引是否“有效”，不能只盯 key 和 type，得看 ROWS_EXAMINED 和执行期间是否触发磁盘临时表或排序。很多“用了索引还慢”的 case，本质是把索引当全表扫描用，或者用错索引顺序。
