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（假设
a4B +
b12B +
c1B 时间戳精度标记），才表示三列都有效用于查找。
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的慢查询——它们往往在数据量增长后突然暴雷。
