mysql中的查询计划生成与执行顺序

EXPLAIN 的 rows 表示优化器估算的该节点需扫描或检查的行数，非返回客户端行数；受索引选择、条件顺序及统计信息影响，显著偏大常意味缺索引或索引未被选用。

mysql中的查询计划生成与执行顺序第1张

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 pe 或 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 条件下推到存储引擎层过滤，减少回表次数。