EXPLAIN 的 rows 表示优化器估算的该节点需扫描或检查的行数，非返回客户端行数；受索引选择、条件顺序及统计信息影响，显著偏大常意味缺索引或索引未被选用。
EXPLAIN 输出的 rows 字段到底代表什么
它不是最终返回给客户端的行数，而是 MySQL 优化器估算的「该节点需要扫描或检查的行数」。这个值受索引选择、条件过滤顺序、统计信息准确性直接影响。比如 WHERE a = 1 AND b > 10，如果只有 a 上有索引，rows 可能显示匹配 a = 1 的所有行；而如果 (a, b) 是联合索引，rows 往往更小，因为 b > 10 也能在索引内完成范围扫描。
- 执行
ANALYZE TABLE t能更新统计信息，让rows更贴近实际 -
rows显著大于实际结果集，常意味着缺少合适索引或索引未被选中 - 若
type是ALL且rows接近表总行数，基本确认是全表扫描
MySQL 实际执行顺序不等于 SQL 书写顺序
SELECT 子句里的字段、WHERE 条件、ORDER BY 和 LIMIT 都会被重排。优化器按成本模型决定先走哪个索引、是否下推条件、是否用临时表排序。例如 SELECT name FROM users WHERE status = 1 ORDER BY created_at DESC LIMIT 10，即使没为 created_at 建索引，MySQL 也可能先用 status 索引取出所有 status = 1 的行，再内存排序取前 10 —— 这时 EXPLAIN 的 Extra 会显示 Using filesort。
-
WHERE条件永远最先应用（哪怕写在 SELECT 后面） -
GROUP BY和HAVING在WHERE之后、SELECT字段计算之前执行 -
LIMIT是最后一步，但优化器可能利用它提前终止扫描（如index dive或index range scan中遇到足够行就停）
key_len 值能看出用了联合索引的哪几列
key_len 表示 MySQL 实际使用索引字节数，它由字段类型、是否允许 NULL、字符集共同决定。比如 utf8mb4 字符串字段，每字符占 4 字节；INT 是 4 字节；TINYINT 是 1 字节；每个可为 NULL 的字段额外加 1 字节标记位。
CREATE TABLE t ( a INT, b VARCHAR(10), c DATETIME, KEY idx_abc (a, b, c) );
当 EXPLAIN 显示 key_len = 5，说明只用到了 a 和 b 的前缀（比如 b 是 VARCHAR(10) 但只用了 1 字符），而 c 没参与索引查找。若 key_len = 17（假设 a 4B + b 12B + c 1B 时间戳精度标记），才表示三列都有效用于查找。
-
key_len小于索引定义总长度，大概率是索引最左前缀没用全 - 对
VARCHAR字段做LIKE '%xxx'会导致key_len归零（无法使用索引） - 函数操作字段（如
WHERE YEAR(created_at) = 2023）也会使key_len为 0
Extra 字段里常见的隐藏开销提示
Using temporary 表示 MySQL 创建了内部临时表，常见于 GROUP BY、DISTINCT 或某些 ORDER BY 场景；Using filesort 不一定真写磁盘文件，但表示排序不能直接用索引完成；Using index condition 是 ICP（Index Condition Pushdown），说明部分 WHERE 条件下推到存储引擎层过滤，减少回表次数。
-
Using index（覆盖索引）：查询字段全部命中索引，无需回表 -
Using where; Using index：索引覆盖 + 索引字段上还有额外过滤条件 -
Impossible WHERE：优化器静态判断 WHERE 永假（如id = 1 AND id = 2），直接返回空结果
真正难调的是那些没报错、没告警，但 Extra 里悄悄出现 Using temporary 和 Using filesort 的慢查询——它们往往在数据量增长后突然暴雷。
