EXPLAIN on Liangweidong's blog

MySQL 实战速查：EXPLAIN 全字段解读 + 经典 SQL 题解

Mon, 15 Jun 2015 00:00:00 +0800

为什么写这篇：EXPLAIN 是 MySQL 调优的"听诊器"，但官方文档对 key_len、filtered、Extra 这些字段解释过于简略。本文用真实 SQL 示例把每个字段的含义讲透，并配 9 道 SQL 笔试题的标准解法——这些题在笔试/面试中重复率极高。

适用读者：需要做 SQL 优化的后端、面试准备、想系统性梳理 SQL 语法的同学。

前置知识：会基本 SQL，了解索引概念。

1. EXPLAIN 基础：一个完整案例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


EXPLAIN
SELECT F_LogId AS logId, F_CategoryId AS categoryId,
 F_SourceObjectId AS sourceObjectId,
 F_SourceContentJson AS sourceContentJson,
 F_OperateTime AS operateTime,
 F_OperateUserId AS operateUserId
FROM base_log
WHERE F_DeleteMark = 0
 AND (F_DeleteMark = 0)
ORDER BY F_OperateTime DESC
LIMIT 15;

第一次 EXPLAIN 输出：

id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	Extra
1	SIMPLE	base_log		ALL					1320000	10.00	Using where; Using filesort

type=ALL 是全表扫描。rows=1320000 表示扫描 132 万行。Using filesort 表示额外排序。

优化一：加索引

1

CREATE INDEX idx_OperateTime ON base_log (F_OperateTime);

第二次 EXPLAIN 输出：

id	select_type	table	type	key	key_len	rows	Extra
1	SIMPLE	base_log	index	idx_OperateTime	8	15	Using where; Backward index scan

type 从 ALL 升级到 index（全索引扫描）
rows 从 132 万降到 15（只用 LIMIT 15 即可）
Extra 出现 Backward index scan（对 F_OperateTime 倒序扫，命中 ORDER BY DESC）

结论：单列索引 + LIMIT 优化，让 132 万行扫描变成 15 行扫描，性能从秒级降到毫秒级。

2. EXPLAIN 字段逐列解读

字段	含义
`id`	SELECT 标识符。同一个 SELECT 共享 id；子查询/UNION 会递增
`select_type`	查询类型（SIMPLE / PRIMARY / UNION / SUBQUERY / DEPENDENT SUBQUERY）
`table`	当前行访问的表
`partitions`	匹配的分区（如果表是分区表）
`type`	最重要：join 类型，决定性能等级
`possible_keys`	优化器考虑使用的索引（不一定会用）
`key`	实际使用的索引
`key_len`	索引使用的字节数（可判断复合索引用了几个字段）
`ref`	哪个字段或常数与 key 一起被使用
`rows`	优化器估算要扫描的行数（实际可能偏差巨大）
`filtered`	过滤后剩余行数百分比
`Extra`	额外信息（`Using filesort` / `Using temporary` / `Using index` 等）

2.1 select_type 常见取值

SIMPLE：不含 UNION 和子查询的最简单查询
PRIMARY：最外层 SELECT
UNION：UNION 的第二或随后的查询
SUBQUERY：子查询中的第一个 SELECT
DEPENDENT SUBQUERY：依赖外层查询结果的子查询（通常很慢）

3. type 性能等级排序

从最差到最好：

1

ALL < index < range ~ index_merge < ref < eq_ref < const < system

type	含义	性能
`system`	表中只有 1 条数据	最佳
`const`	主键/唯一索引等值扫描，最多 1 行	极佳
`eq_ref`	多表 JOIN，每个前表结果只匹配后表 1 行	很好
`ref`	非唯一索引等值扫描，或最左前缀命中	好
`range`	索引范围扫描（=、<、>、BETWEEN、IN）	中
`index`	全索引扫描（不读数据文件）	较差
`ALL`	全表扫描	最差

底线：你的 SQL 不应该出现 type=ALL——除非表只有几十行，或者确实没有合适的过滤条件。

4. key_len 的字节数计算规则

key_len 能告诉你复合索引里实际用到了几个字段。

4.1 基础计算公式

字符串：

char(n)：n 字节
varchar(n)：
- utf8 编码：3 * n + 2 字节（2 是长度前缀）
- utf8mb4 编码：4 * n + 2 字节

数值：

类型	字节
TINYINT	1
SMALLINT	2
MEDIUMINT	3
INT	4
BIGINT	8

时间：

类型	字节
DATE	3
TIMESTAMP	4
DATETIME	8

字段属性：如果字段允许 NULL，多算 1 字节。

4.2 实战算例

1

KEY idx_name_age (name varchar(50), age int, dept varchar(20))

索引长度计算：

name varchar(50) utf8mb4：50 * 4 + 2 + 1 = 203（含 NULL 标志）
age int NOT NULL：4
dept varchar(20) utf8mb4：20 * 4 + 2 + 1 = 83

SQL 条件	命中索引	key_len
`WHERE name = 'a'`	name	203
`WHERE name = 'a' AND age = 10`	name + age	207
`WHERE name = 'a' AND age = 10 AND dept = 'b'`	全部	290
`WHERE age = 10`	无	NULL（不满足最左前缀）

关键洞察：key_len 越大说明用到的索引字段越多。如果 key_len 跟你期望的不一致，往往是漏写了等值条件或写错了列顺序。

5. Extra 常见提示与优化方向

Extra	含义	优化方向
`Using filesort`	额外的排序操作（不能用索引顺序）	让 ORDER BY 命中复合索引顺序
`Using temporary`	使用了临时表（GROUP BY / DISTINCT）	让 GROUP BY 命中索引
`Using index`	覆盖索引：只在索引里取数据，不回表	目标
`Backward index scan`	倒序索引扫描	通常对 `ORDER BY DESC` 是好事
`Using where`	存在 WHERE 子句筛选	配合 type 看
`Using index condition`	索引下推（ICP，5.6+）	通常是好事
`Impossible WHERE`	WHERE 永远为 false	删掉这种 SQL

6. 9 道经典 SQL 笔试题

表结构（学生选课经典案例）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


CREATE TABLE student (
 id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
 name CHAR(10) NOT NULL
);
INSERT INTO student(name) VALUES ('张三'),('李四');

CREATE TABLE course (
 id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
 name CHAR(20) NOT NULL
);
INSERT INTO course(name) VALUES ('语文'),('数学');

CREATE TABLE student_course (
 sid INT UNSIGNED,
 cid INT UNSIGNED,
 score INT UNSIGNED NOT NULL,
 FOREIGN KEY (sid) REFERENCES student(id),
 FOREIGN KEY (cid) REFERENCES course(id),
 PRIMARY KEY(sid, cid)
);
INSERT INTO student_course VALUES (1,1,80),(1,2,90),(2,1,90),(2,2,70);

6.1 查重名学生

1
2
3
4
5
6


SELECT id, name
FROM student
WHERE name IN (
 SELECT name FROM student GROUP BY name HAVING COUNT(*) > 1
)
ORDER BY name;

关系型数据库查重复行的通用套路：GROUP BY + HAVING COUNT > 1 + 子查询。

6.2 平均分不及格的学生

1
2
3
4


SELECT sid, AVG(score) AS avg_score
FROM student_course
GROUP BY sid
HAVING avg_score < 60;

WHERE 过滤记录，HAVING 过滤分组。聚集函数（AVG/COUNT/SUM）只能放 HAVING 里。

6.3 每门课都不低于 80 分的学生

1
2
3
4
5


SELECT DISTINCT sid
FROM student_course
WHERE sid NOT IN (
 SELECT sid FROM student_course WHERE score < 80
);

反向思维：要求"所有都 >= 80"等价于"不存在 < 80 的"。这是数理逻辑里的 ∀x:P ≡ ¬∃x:¬P。

6.4 每个学生的总成绩（含没成绩的）

1
2
3
4


SELECT name, SUM(score) AS total
FROM student
 LEFT JOIN student_course ON student.id = student_course.sid
GROUP BY sid;

INNER JOIN 会过滤掉没成绩的学生。用 LEFT JOIN 才能保留。

6.5 总成绩最高的学生

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


-- 标准解法
SELECT sid, SUM(score) AS sum_score
FROM student_course
GROUP BY sid
ORDER BY sum_score DESC
LIMIT 1;

-- 错误解法（虽然能跑，但语义反了）
SELECT sid, SUM(score) AS sum_score
FROM student_course
GROUP BY sid
HAVING sum_score >= ALL (
 SELECT SUM(score) FROM student_course GROUP BY sid
);

6.6 第 N 高的分数

1
2
3
4
5
6
7


-- 课程 1 第 2 高的分数
SELECT score
FROM student_course
WHERE cid = 1
GROUP BY score
ORDER BY score DESC
LIMIT 1, 1; -- offset=1, count=1

常见错误：LIMIT 2 然后 MIN(score)——因为执行顺序是 GROUP BY → MIN → ORDER BY → LIMIT，MIN 后 ORDER BY 已经无意义。

正确做法是用 LIMIT offset, count 跳过的语法。

6.7 每门课最高分的学生（核心）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


-- 错误写法（MySQL 不会报错，但 sid 是无效的）
SELECT sid, cid, MAX(score)
FROM student_course
GROUP BY cid;

-- 正确写法：相关子查询
SELECT *
FROM student_course AS x
WHERE score >= (
 SELECT MAX(score) FROM student_course AS y WHERE cid = x.cid
);

GROUP BY 后的 SELECT 字段只能是：① GROUP BY 字段；② 聚集函数；③ 每个分组内均相同的字段。MySQL 的扩展语法（sid）默认开了 ONLY_FULL_GROUP_BY 是会拒绝的。

6.8 每门课的前 N 名

1
2
3
4
5
6
7
8
9


-- 每门课前 2 名
SELECT *
FROM student_course AS x
WHERE 2 > (
 SELECT COUNT(*)
 FROM student_course AS y
 WHERE y.cid = x.cid AND y.score > x.score
)
ORDER BY cid, score DESC;

核心思想：对于某个分数，如果同课程下比它高的分数少于 N 个，那么它就是前 N 名之一。

6.9 比赛两两组合

1
2
3
4


-- 4 队两两比赛，列出所有可能的比赛组合
SELECT a.name, b.name
FROM team a, team b
WHERE a.name < b.name;

自连接 + 不等式：本质是 team 表和自己做笛卡尔积，再过滤掉 a=b 和 a>b 的重复。

MySQL 索引优化实战：700 万行表从 3 秒到 50 毫秒

Mon, 15 Dec 2014 00:00:00 +0800

为什么写这篇：很多教程讲索引原理头头是道，但真碰到 700 万行、6 张表 join、含 GROUP BY 和 ORDER BY 的复杂 SQL 时，仍是无从下手。本文还原一次完整的"看 EXPLAIN → 找瓶颈 → 设计索引 → 上线验证"过程，所有 SQL 都在 INPLACE LOCK=NONE 下执行，不阻塞业务读写。

适用读者：在生产库做 SQL 优化的后端 / DBA，需要 INPLACE 在线 DDL 经验。

前置知识：了解 B+ 树索引、EXPLAIN 各字段含义、InnoDB 在线 DDL。

1. 场景还原：3 秒的复杂 SQL

业务背景：某安全风险排查平台，要查"过去一个月内、某岗位/某单位/某风险点下的排查任务"，分页展示。

表数据量：

表名	含义	估算行数
`risk_task`	排查任务主表	100 万
`risk_task_info`	任务时间信息表	700 万
`risk_ctrl`	风险管控措施	50 万
`risk_info`	风险点信息	5 万
`risk_unit`	风险单元	5000
`risk_object`	风险对象	2000
`dangersrc`	危险源	500

原始 SQL（6 张表 join，3 排序字段，分页 20）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


EXPLAIN
SELECT
 hprt.id AS task_id,
 hprg.id AS main_id,
 hprt.create_time,
 hprti.begin_time,
 hprti.end_time,
 hprt.check_time,
 hprt.check_user_id,
 hprt.check_status,
 CASE
 WHEN hprt.check_status = 0 AND hprti.end_time >= NOW() AND hprti.begin_time <= NOW() THEN '10'
 WHEN hprt.check_status = 2
 OR (hprt.check_status = 0 AND hprti.end_time < NOW()) THEN '11'
 WHEN hprt.check_status = 1 THEN '20'
 END AS STATUS,
 hpro.risk_object_name,
 hpru.risk_unit_name,
 hpd.dangersrc_name,
 hpri.risk_info,
 hpru.risk_type,
 hpri.risk_level,
 hprc.F_Id AS ctrl_id,
 hprc.screening_type,
 hprc.screening_num,
 hprc.screening_department,
 hprc.screening_position,
 hprc.post_psn_id,
 hprc.ctrl_measure,
 hprc.hd_content,
 hprc.post_psn_name,
 hpro.F_CreateUserId
FROM
 risk_task hprt
 INNER JOIN risk_task_info hprti USE INDEX (index_begin_time)
 ON hprt.task_info_id = hprti.task_info_id
 INNER JOIN risk_ctrl hprc
 ON hprt.ctrl_id = hprc.F_Id AND hprc.F_DeleteMark = 0
 INNER JOIN risk_info hpri
 ON hprc.risk_id = hpri.F_Id AND hpri.F_DeleteMark = 0
 INNER JOIN risk_unit hpru
 ON hpri.risk_unit_id = hpru.F_Id AND hpru.F_DeleteMark = 0
 INNER JOIN risk_object hpro
 ON hpru.risk_object_id = hpro.F_Id AND hpru.F_DeleteMark = 0
 INNER JOIN dangersrc hpd
 ON hpri.dangersrc_id = hpd.F_Id AND hpd.F_DeleteMark = 0
 LEFT JOIN risk_governance hprg
 ON hprg.task_id = hprt.id
WHERE
 hprt.F_DeleteMark = 0
 AND hprti.begin_time <= NOW()
 AND hprti.begin_time >= '2025-09-9 00:00:00'
 AND '2025-09-9 23:59:59' >= hprti.begin_time
ORDER BY
 hpro.risk_object_name,
 hpru.risk_unit_name,
 hprti.begin_time DESC,
 hprt.check_time DESC
LIMIT 20;

实测耗时：3.1 秒（业务方强烈要求压到 1 秒内）。

2. 第一次 EXPLAIN：定位瓶颈

跑 EXPLAIN 后重点看 3 个字段：

id	table	type	key	rows	Extra
1	hprti	range	index_begin_time	21548	Using index condition; Using temporary; Using filesort
1	hprt	ref	index_task_info_id	1	Using where
1	hprc	eq_ref	PRIMARY	1	Using where
1	hpri	eq_ref	PRIMARY	1	Using where
1	hpru	eq_ref	PRIMARY	1	Using where
1	hpro	eq_ref	PRIMARY	1	—
1	hpd	eq_ref	PRIMARY	1	Using where
1	hprg	ref	index_task_id	16	Using where; Using index

两个关键信号：

Using temporary：MySQL 在内存中建了一张临时表
Using filesort：在临时表上做了文件排序

这俩同时出现意味着：当前索引对 ORDER BY 的顺序毫无贡献，MySQL 只能把所有满足条件的行拉到临时表里再排。

driver 表的索引问题：

hprti 表上只有：

1
2


KEY `index_end_time` (`end_time`)
KEY `index_begin_time` (`begin_time`) -- 范围过滤用了

这个单列索引对 ORDER BY hprti.begin_time DESC 有帮助（Backward index scan），但对 4 个字段的复合排序完全不够。

3. 索引设计原则：覆盖索引 + 复合索引顺序

按"驱动表先建、JOIN 列次之、ORDER BY 列最后"的原则设计复合索引。

3.1 驱动表 `risk_task_info`：覆盖 WHERE + JOIN + ORDER BY

1
2
3
4
5


-- 旧索引（删）
KEY `index_begin_time` (`begin_time`)

-- 新索引：begin_time（过滤）+ task_info_id（JOIN hprt）+ end_time（覆盖 WHERE）
KEY `index_begin_time` (`begin_time`, `task_info_id`, `end_time`)

复合索引列顺序铁律：等值查询 > 范围查询 > 排序。这里 begin_time 是范围过滤，放最前；task_info_id 是等值 JOIN 字段放第二；end_time 顺手覆盖到 WHERE 条件。

3.2 关联表 `risk_object`：覆盖 JOIN + ORDER BY

1
2
3


-- 排序第一字段是 risk_object_name
-- JOIN 字段是 F_Id
KEY `idx_risk_object_name` (`risk_object_name`, `F_Id`)

3.3 关联表 `risk_unit`：覆盖 JOIN + ORDER BY + JOIN

1
2
3
4
5


-- 删除旧索引
KEY `index_object_id` (`risk_object_id`)

-- 新索引：risk_object_id（JOIN hpro）+ risk_unit_name（排序）+ F_Id（JOIN hpri）
KEY `idx_risk_unit_covering` (`risk_object_id`, `risk_unit_name`, `F_Id`)

3.4 关联表 `risk_task`：覆盖 JOIN + 过滤 + 排序

1
2
3
4
5
6


-- 删除旧索引
KEY `index_task_info_id` (`task_info_id`)
KEY `index_ctrl_id` (`ctrl_id`)

-- 新索引：task_info_id（JOIN hprti）+ F_DeleteMark（过滤）+ ctrl_id（JOIN hprc）+ check_time（排序）
KEY `idx_task_covering` (`task_info_id`, `F_DeleteMark`, `ctrl_id`, `check_time`)

4. 实施步骤：INPLACE 在线 DDL

MySQL 5.6+ 支持在线加索引：ALGORITHM=INPLACE + LOCK=NONE。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


-- 1. 删旧索引（INPLACE 操作，瞬间完成）
ALTER TABLE risk_task_info
 ALGORITHM = INPLACE,
 DROP INDEX index_begin_time;

-- 2. 加新索引（INPLACE，不锁表）
ALTER TABLE risk_task_info
 ALGORITHM = INPLACE,
 ADD INDEX idx_hprti_time_covering (begin_time, task_info_id, end_time);

-- 3. 改名复用（SQL 写死了 USE INDEX (index_begin_time)，不能改名）
ALTER TABLE risk_task_info
 ALGORITHM = INPLACE,
 RENAME INDEX idx_hprti_time_covering TO index_begin_time;

-- 4. risk_object 加索引
ALTER TABLE risk_object
 ALGORITHM = INPLACE,
 ADD INDEX idx_risk_object_name (risk_object_name, F_Id);

-- 5. risk_unit 替换索引
ALTER TABLE risk_unit
 ALGORITHM = INPLACE,
 DROP INDEX index_object_id;

CREATE INDEX idx_risk_unit_covering ON risk_unit(
 risk_object_id, risk_unit_name, F_Id
) ALGORITHM = INPLACE;

-- 6. risk_task 替换索引
ALTER TABLE risk_task
 ALGORITHM = INPLACE,
 DROP INDEX index_task_info_id,
 DROP INDEX index_ctrl_id;

CREATE INDEX idx_task_covering ON risk_task(
 task_info_id, F_DeleteMark, ctrl_id, check_time
) ALGORITHM = INPLACE;

实操记录：

操作	表大小	耗时
DROP + ADD + RENAME `index_begin_time`	700 万行	57 秒
DROP + CREATE `idx_risk_unit_covering`	5000 行	< 1 秒
DROP + CREATE `idx_task_covering`	100 万行	128 秒

700 万行上加复合索引耗时 57 秒，期间应用读写不阻塞（INPLACE LOCK=NONE）。这就是 MySQL 5.6+ 最大的运维红利——以前做这种事要停机维护。

5. 第二次 EXPLAIN：瓶颈消除

id	table	type	key	rows	Extra
1	hprti	range	index_begin_time	21548	Using index condition; Backwards index scan
1	hprt	ref	idx_task_covering	1	Using where
1	hprc	eq_ref	PRIMARY	1	Using where
1	hpri	eq_ref	PRIMARY	1	Using where
1	hpru	eq_ref	idx_risk_unit_covering	1	Using where
1	hpro	eq_ref	idx_risk_object_name	1	—
1	hpd	eq_ref	PRIMARY	1	Using where
1	hprg	ref	index_task_id	16	Using where; Using index

变化：

Using temporary 消失
Using filesort 消失
出现 Backwards index scan（对 index_begin_time 倒序扫，刚好满足 ORDER BY ... DESC）

实际耗时：从 3.1 秒 → 0.18 秒（17 倍提升），单次压测稳定在 50~180ms 区间。

6. CTE + GROUP BY 场景的索引设计

业务方后来又加了个"按风险对象统计完成率"的需求，用到了 CTE + GROUP BY：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


WITH baseInfos AS (
 SELECT d.F_Id AS mId, c.F_Id AS tId, b.F_Id AS oId, a.F_Id AS lId,
 d.NAME AS NAME, a.work_type AS workType
 FROM risk_ctrl a
 INNER JOIN risk_info b ON a.risk_id = b.F_Id
 INNER JOIN risk_object c ON b.risk_object_id = c.F_Id
 INNER JOIN hazard_major_management d ON d.identifier = c.riskobject_code
 WHERE b.F_DeleteMark = 0
 AND c.F_DeleteMark = 0
 AND d.F_DeleteMark = 0
 AND a.work_type IN ('1', '2', '3')
)
SELECT
 t.*,
 p.person_in_charge_main main,
 p.person_in_charge_technical technical,
 p.person_in_charge_operation operation
FROM (
 SELECT
 baseInfos.mId id,
 baseInfos.workType,
 baseInfos.NAME riskObjectName,
 date_format(info.begin_time, '%Y-%m-%d') beginTime,
 date_format(info.end_time, '%Y-%m-%d') endTime,
 IF(count(1) = sum(IF(k.check_status = 1, 1, 0)), '已完成', '未完成') AS checkStatus,
 sum(k.is_risk) hdCount,
 max(k.check_time) checkTime,
 k.check_user_id checkUser
 FROM risk_task k
 INNER JOIN risk_task_info info ON k.task_info_id = info.task_info_id
 INNER JOIN baseInfos ON k.ctrl_id = baseInfos.lId
 WHERE k.F_DeleteMark = 0
 GROUP BY
 baseInfos.mId,
 IF(checkUser IS NULL OR checkUser = '', baseInfos.workType, checkUser),
 info.begin_time,
 info.end_time
 ORDER BY info.begin_time DESC
) t
LEFT JOIN hazard_major_management p ON t.id = p.F_Id
LIMIT 20;

关键索引：

1
2
3
4
5
6
7
8
9


-- 覆盖过滤 + JOIN + 排序
CREATE INDEX idx_k_covering ON risk_task
 (F_DeleteMark, ctrl_id, task_info_id, check_time)
 ALGORITHM = INPLACE LOCK = NONE;

-- 覆盖 JOIN + 排序
CREATE INDEX idx_info_covering ON risk_task_info
 (task_info_id, begin_time, end_time)
 ALGORITHM = INPLACE LOCK = NONE;

CTE 本身不会自动建立索引，所以外层 JOIN 用到的字段（ctrl_id、task_info_id）必须在底层表上有索引。

7. 经验总结

7.1 三类必看 EXPLAIN 字段

字段	出现什么	优化方向
`type`	`ALL`	必须加索引
`Extra`	`Using filesort`	ORDER BY 字段没有命中索引顺序
`Extra`	`Using temporary`	GROUP BY / DISTINCT 没有命中索引顺序
`rows`	大于实际过滤后行数	索引选择度不够

7.2 复合索引列顺序铁律

1

等值过滤 > 范围过滤 > 排序 > 覆盖字段

错误示范：(order_field, where_field, id) —— 排序字段放最前，会导致 ORDER BY 之后无法再用 WHERE 字段做范围过滤。

7.3 INPLACE DDL 安全守则

守则	原因
先 DROP 旧索引再 ADD 新索引	避免索引膨胀导致 buffer pool 命中率下降
`LOCK = NONE` 必须显式写	不写默认可能是 `LOCK = SHARED`
一次 DDL 只动一张表	减少主从延迟
大表 DDL 前先在从库试	主从切换可用

7.4 不能光看 EXPLAIN 推算耗时

EXPLAIN 输出的 rows 是估算，不是实际扫描行数。type=ref 估算 1 行，真实扫了 50 万行的案例比比皆是。必须以 SELECT BENCHMARK() 或业务压测的真实耗时为准。

下一步

EXPLAIN 全字段解读 + 经典 SQL 题：见《MySQL 实战速查》
慢查询日志 + sysbench 压测：见《MySQL 慢查询与性能调优》
mysqldump + ibd2sql 备份恢复：见《MySQL 备份恢复实战》

EXPLAIN on Liangweidong's blog

MySQL 实战速查：EXPLAIN 全字段解读 + 经典 SQL 题解

目录

1. EXPLAIN 基础：一个完整案例

2. EXPLAIN 字段逐列解读

2.1 select_type 常见取值

3. type 性能等级排序

4. key_len 的字节数计算规则

4.1 基础计算公式

4.2 实战算例

5. Extra 常见提示与优化方向

6. 9 道经典 SQL 笔试题

6.1 查重名学生

6.2 平均分不及格的学生

6.3 每门课都不低于 80 分的学生

6.4 每个学生的总成绩（含没成绩的）

6.5 总成绩最高的学生

6.6 第 N 高的分数

6.7 每门课最高分的学生（核心）

6.8 每门课的前 N 名

6.9 比赛两两组合

MySQL 索引优化实战：700 万行表从 3 秒到 50 毫秒

目录

1. 场景还原：3 秒的复杂 SQL

2. 第一次 EXPLAIN：定位瓶颈

3. 索引设计原则：覆盖索引 + 复合索引顺序

3.1 驱动表 `risk_task_info`：覆盖 WHERE + JOIN + ORDER BY

3.2 关联表 `risk_object`：覆盖 JOIN + ORDER BY

3.3 关联表 `risk_unit`：覆盖 JOIN + ORDER BY + JOIN

3.4 关联表 `risk_task`：覆盖 JOIN + 过滤 + 排序

4. 实施步骤：INPLACE 在线 DDL

5. 第二次 EXPLAIN：瓶颈消除

6. CTE + GROUP BY 场景的索引设计

7. 经验总结

7.1 三类必看 EXPLAIN 字段

7.2 复合索引列顺序铁律

7.3 INPLACE DDL 安全守则

7.4 不能光看 EXPLAIN 推算耗时

下一步

EXPLAIN on Liangweidong's blog

MySQL 实战速查：EXPLAIN 全字段解读 + 经典 SQL 题解

目录

1. EXPLAIN 基础：一个完整案例

2. EXPLAIN 字段逐列解读

2.1 select_type 常见取值

3. type 性能等级排序

4. key_len 的字节数计算规则

4.1 基础计算公式

4.2 实战算例

5. Extra 常见提示与优化方向

6. 9 道经典 SQL 笔试题

6.1 查重名学生

6.2 平均分不及格的学生

6.3 每门课都不低于 80 分的学生

6.4 每个学生的总成绩（含没成绩的）

6.5 总成绩最高的学生

6.6 第 N 高的分数

6.7 每门课最高分的学生（核心）

6.8 每门课的前 N 名

6.9 比赛两两组合

MySQL 索引优化实战：700 万行表从 3 秒到 50 毫秒

目录

1. 场景还原：3 秒的复杂 SQL

2. 第一次 EXPLAIN：定位瓶颈

3. 索引设计原则：覆盖索引 + 复合索引顺序

3.1 驱动表 risk_task_info：覆盖 WHERE + JOIN + ORDER BY

3.2 关联表 risk_object：覆盖 JOIN + ORDER BY

3.3 关联表 risk_unit：覆盖 JOIN + ORDER BY + JOIN

3.4 关联表 risk_task：覆盖 JOIN + 过滤 + 排序

4. 实施步骤：INPLACE 在线 DDL

5. 第二次 EXPLAIN：瓶颈消除

6. CTE + GROUP BY 场景的索引设计

7. 经验总结

7.1 三类必看 EXPLAIN 字段

7.2 复合索引列顺序铁律

7.3 INPLACE DDL 安全守则

7.4 不能光看 EXPLAIN 推算耗时

下一步

3.1 驱动表 `risk_task_info`：覆盖 WHERE + JOIN + ORDER BY

3.2 关联表 `risk_object`：覆盖 JOIN + ORDER BY

3.3 关联表 `risk_unit`：覆盖 JOIN + ORDER BY + JOIN

3.4 关联表 `risk_task`：覆盖 JOIN + 过滤 + 排序