企业官网建设流程全解析

1. 先把话说透：面试官问B+树到底在考什么

“MySQL索引为什么用B+树”——这道题在技术面试里的出现频率，大概相当于手写单例模式在十年前的地位。很多人背得滚瓜烂熟：B+树矮胖、非叶子节点不存数据、叶子节点有链表、范围查询快。背完面试官点点头，然后追问一句“那你说说为什么不用B树”，就开始卡壳了。我面过不少人，也被人面过不少次，慢慢发现这道题根本不是考背诵，它是一块敲门砖，敲的是你对存储引擎、磁盘IO、数据结构取舍这三件事的理解深度。

先把结论摆出来：MySQL的InnoDB引擎选择B+树作为索引结构，本质上是在磁盘这种慢速随机访问介质上，用最少的IO次数定位到目标数据，同时尽可能少地浪费存储空间。这句话里的每一个限定词都有用。换成内存数据库，Redis用跳表就够了；换成只做等值查询的KV场景，哈希索引可能更快；换成写多读少的日志型场景，LSM树才是正解。B+树不是什么“最优解”，它是在“读多写少、范围查询多、数据量大到内存装不下”这个具体场景下的最优解，而这个场景恰好覆盖了绝大多数业务系统的数据库需求。

这篇文章我想按我自己的理解路径来写，不搞那种“定义-特点-优点”的教科书式罗列。我会从磁盘IO的成本算起，把B+树的结构掰开揉碎，然后落到InnoDB实际的索引组织方式上，最后给一批面试里反复出现的实操题和排查思路。适合两类人看：一类是正在准备面试、想从“背答案”升级到“讲清楚”的；另一类是工作几年了，索引建了一堆但说不清为什么这么建的。文章里涉及的数字和参数我都会给出计算过程，你可以自己拿笔跟着算一遍，算完基本就忘不掉了。

1.1 一道被问烂的题，其实是三层考点

面试官抛出“为什么用B+树”的时候，他脑子里通常有三个评分档位。第一档是能说出B+树的形态特征：非叶子节点只存键和指针、所有数据都在叶子节点、叶子节点之间用双向链表串起来。这一档只是及格线，说明你看过资料。第二档是能解释这些特征对应解决什么问题：非叶子节点不存数据所以单页能放更多键，树就更矮，IO次数更少；数据全在叶子所以每次查询的IO次数稳定；叶子链表让范围查询和排序不用回到根节点重新走。能讲到这一层，说明你理解了设计意图。

第三档，也是真正拉开差距的一层，是能把这个选择和具体引擎、具体业务场景绑定起来讲。比如你能说清楚InnoDB的聚簇索引为什么把整行数据挂在主键B+树的叶子节点上，二级索引为什么要回表，为什么主键建议用自增而不是UUID，为什么联合索引的字段顺序会影响查询效率。这些问题背后是同一条主线：B+树是一个有序的、分层的、页为单位的结构，你对它的所有困惑，归根结底都是没把“有序”和“页”这两个词吃透。

我个人的经验是，面试时如果你只答第一档，面试官可能会再给你一次机会追问；如果你能主动过渡到第二档，面试节奏就掌握在你手里了；如果你能把第三档里跟你项目相关的那部分讲出来——比如“我们那套订单系统之前主键用的雪花ID，插入的时候页分裂比较严重，后来换成自增主键，写入性能提升了大概多少”——那这道题基本就稳了。

1.2 别急着背结论，先建立“页”的直觉

很多人学B+树学得别扭，是因为脑子里没有“页”这个概念，把B+树当成一个抽象的树结构在记。实际上InnoDB操作数据的最小单位是页，默认大小16KB。你查一行数据，引擎不是从磁盘上抠出这一行，而是把包含这行的整个16KB页读到内存的Buffer Pool里。哪怕你只要一个字段，也是读一整页。这个设定决定了后面所有的设计取舍。

打个比方，页就像是一本字典里的一页纸，B+树就是这套字典的目录体系。你要找一个字，不是从第一页翻起，而是先看总目录定位到大概在哪一册，再看分册目录定位到哪一章，最后翻到那一页。每一层目录都是一次“IO”，而IO是这个体系里最贵的动作。所以整个数据结构的设计目标就一句话：让目录层尽可能薄，让每一页目录尽可能装下更多条目，从而把“翻目录”的次数压到最低。理解了这个，你再看B+树非叶子节点为什么只存键不存数据，就变得非常自然了——因为存了数据，一页能放的键就少了，目录就厚了，树就高了，IO就多了。

2. B+树的骨架：从磁盘IO的成本算起

聊数据结构不谈硬件特性就是耍流氓。内存里比较两个指针的开销大概是纳秒级，而一次机械硬盘的随机读是毫秒级，两者差了六个数量级。就算是现在普及的SSD，随机读也在几十到上百微秒，跟内存访问依然差着好几个量级。这意味着在数据库这个场景里，“比较次数”几乎不值钱，“IO次数”极其值钱。所有面向磁盘的数据结构，优化的核心指标都是IO次数，而不是时间复杂度里的比较次数。

这就能解释一个很多人疑惑的点：二叉搜索树查找的时间复杂度是O(log n)，B+树也是O(log n)，凭什么B+树更快？因为这里的log底数不一样。二叉树每层只能把范围缩小一半，100万条数据要走20层；B+树一个节点是一整页16KB，能放几百上千个键，每层能把范围缩小上千倍，100万条数据三层就够了。20次IO和3次IO的差距，在磁盘上就是几十毫秒和零点几毫秒的差距。复杂度记号相同，实际代价天差地别。

2.1 一次磁盘IO到底有多贵

我们把数字摆出来看。假设一块普通的SATA SSD，4K随机读的IOPS大概在几万这个量级，换算下来单次随机读的延迟在几十微秒到一百微秒之间。听着不多，但数据库查询往往不是一次IO就完事。如果没有索引，一张一千万行的表做全表扫描，按每页16KB、每行200字节算，一页大概装80行，总共需要读12.5万个页。就算全部走顺序读、就算有预读优化，这个量级也是几百毫秒起步，稍微并发高一点直接把磁盘打满。

有索引的情况就完全不同了。一千万行的表，三层B+树，定位一行只需要读三次页：根页、中间页、叶子页。而且根页和中间页由于被频繁访问，大概率常驻在Buffer Pool里，实际的物理IO可能只有一次，甚至零次。这就是索引存在的全部意义——把O(n)的扫描变成O(log n)的定位。

这里有个容易忽略的细节：InnoDB在读取页的时候，除了读目标页，还会触发预读机制。线性预读会在顺序访问一个区（64个页）中的一定数量页后，把整个区预读到内存；随机预读则在一个区中已经缓存了一定数量页时，把剩余页读进来。这个机制对全表扫描和范围查询帮助很大，但对点查基本没影响。面试里如果有人问你“B+树点查一定要三次IO吗”，你可以补一句“根节点常驻内存、加上预读和自适应哈希索引，实际物理IO往往更少”，这个回答的层次就上去了。

2.2 B+树、B树、哈希、红黑树横向对比

光说B+树好，不如把候选方案摆一桌对比。面试里最常被拿来对照的是B树、哈希索引和二叉平衡树，我做了个表，把关键差异列清楚：

B树和B+树最本质的区别在两点。第一，B树的非叶子节点也存数据。这意味着一页16KB里，能放的键数量会大幅减少。假设一个键4字节、指针6字节，B树存了数据之后每条记录可能要占几百字节，一页只能放几十个键；B+树非叶子节点只有键和指针，一页能放上千个键。同样的数据量，B树的树高会明显更高，IO次数更多。

第二，B+树的叶子节点之间用双向链表连接，而且所有数据都集中在叶子层。这让范围查询变得极其自然：定位到起始位置后，顺着链表往后扫就行。B树因为数据分散在各层，做范围查询需要中序遍历，要在不同层级之间来回跳，实现复杂且效率低。你想想where id between 100 and 200这种查询，B+树找到100所在的叶子，然后顺着链表读几页就完事了，B树得一层层回溯，差距非常明显。

哈希索引的问题更直接：它只能做等值匹配。where name = 'xxx'飞快，但你写个where age > 18，它直接废掉。而且哈希索引不支持最左前缀，不支持排序，一旦出现哈希冲突还要链表遍历。所以InnoDB只在特定场景下用自适应哈希索引作为辅助，主索引结构从来不是哈希。Memory引擎倒是支持哈希索引，但那是内存场景，不涉及磁盘IO的取舍。

2.3 三层B+树到底能存多少行，算给你看

这个计算是面试里的加分项，因为它能证明你不是在背书。假设InnoDB页大小16KB，主键是bigint占8字节，页内指针占6字节，那么非叶子节点的一条索引记录是14字节。一页能放的记录数约等于 16384 / 14 ≈ 1170 条。也就是说每个非叶子节点可以指向1170个子节点。

再看叶子节点。假设一行数据平均1KB（这个估算对业务表来说偏大，实际很多表一行几百字节），一页能放16行。那么：

• 树高为2（一个根节点+一层叶子）：1170 × 16 ≈ 1.87万行
• 树高为3（根+中间层+叶子）：1170 × 1170 × 16 ≈ 2190万行
• 树高为4：1170³ × 16 ≈ 256亿行

结论就是，一张两千万行左右的表，B+树只有三层，任何一次点查最多三次页访问。这就是为什么InnoDB能扛住千万级数据量还保持毫秒级响应。你可以把这个计算过程记下来，面试时主动算一遍，效果比干说“B+树很矮”强得多。

顺便说一句，如果一行数据平均只有200字节，一页能放80行，那三层B+树能存到1.1亿行左右。所以真实业务里，只要不是大字段特别多的表，三层B+树基本能覆盖绝大部分场景。这也解释了为什么DBA在评估分库分表时，单表千万级是个常见阈值——不是技术硬限制，而是留出余量、控制维护成本的经验值。

3. InnoDB里的索引真相：数据即索引

理解了B+树这个通用结构，还得落到InnoDB的具体实现上，不然面试官一问“聚簇索引和二级索引的区别”又要露馅。InnoDB有个说法叫索引组织表（Index Organized Table），意思是这张表的数据本身就是按主键B+树组织存储的，没有额外的“数据文件”和“索引文件”之分。你建表时指定的主键，直接决定了数据在磁盘上的物理排列顺序。

这个设计和MyISAM完全不同。MyISAM的索引文件和数据文件是分开的，索引叶子节点存的是数据行的物理地址，查的时候先查索引拿到地址，再去数据文件里取。这种叫非聚簇索引。InnoDB的聚簇索引则把整行数据直接挂在主键B+树的叶子节点上，找到索引就找到了数据，少一次寻址。这也是InnoDB在点查场景下通常比MyISAM快的原因之一。

3.1 聚簇索引：主键就是数据的物理顺序

聚簇索引的叶子节点存的是完整的一行记录，包括所有字段。这意味着两件事。第一，一张表只能有一个聚簇索引，因为数据只能有一种物理排列方式。第二，如果你不指定主键，InnoDB会自动选一个：优先选第一个非空唯一索引，如果没有就用内部生成的6字节隐藏列DB_ROW_ID。用隐藏列做聚簇索引是很糟糕的情况，因为你完全无法控制数据的插入顺序，而且二级索引会变得更大——这个后面讲。

为什么主键推荐自增？核心在于页分裂。B+树的叶子节点是按主键顺序排列的，新插入的记录如果主键是递增的，那么它永远插在当前最后一页的末尾，页写满了就申请新页，这是纯粹的顺序写，非常快。但如果主键是UUID这种随机值，新记录会插到树的中间某个位置，那个位置所在的页可能已经满了，InnoDB就得把这个页拆成两半，把一半数据挪到新页里，再更新上层节点。这个动作叫页分裂，代价包括额外的写IO、页空间利用率下降（分裂后两个页都只用了50%左右）、以及后续查询要访问更多页。

我所在的一个项目早期就踩过这个坑。当时用的是随机字符串做主键，写入压力一大，监控上能看到明显的写入抖动，磁盘写放大很严重。后来换成自增bigint，同样的写入量，P99延迟降了将近一半。这个案例我面试时讲过好几次，面试官的反应基本都是认可的，因为它证明你真的在生产环境里观察过这些现象。

还有一个常被追问的点：自增主键会不会有安全问题，比如暴露业务量、被爬虫遍历。这个确实存在，常见的处理是自增主键只做内部使用，对外暴露一个独立的业务ID字段并加唯一索引。这样既不牺牲写入性能，也不泄露信息。至于自增主键用完后溢出怎么办，bigint无符号能到1844亿亿，正常业务根本用不完，不用操心这个。

3.2 回表：二级索引的代价到底在哪

二级索引（也叫辅助索引）的叶子节点存的不是整行数据，而是索引列的值 + 主键值。这个设计非常关键。查where name = 'abc'的时候，先在name的二级索引上找到对应的主键id，然后拿这个id回到聚簇索引上再查一次，才能拿到完整行数据。这一步就叫回表。

回表的代价是两次B+树查找，如果二级索引命中的记录很多，就是N次回表，每次都是三次页访问。这个成本累加起来相当可观。举个具体的：一张表一千万行，where status = 1命中10万行，如果status上有二级索引，那么执行过程是先扫二级索引找到10万个主键，再回表10万次。优化器一算成本，很可能直接放弃索引走全表扫描——因为全表扫描是顺序读，回表是随机读，10万次随机读可能比扫12.5万个页还慢。

这就是为什么区分度低的字段不适合单独建索引。性别、状态标志、是否删除这类字段，值就那么几种，索引扫出来的记录占比太高，回表成本压过了索引的收益。优化器不傻，它会算成本，很多时候你建了索引它也不用。你可以用explain看key列是不是NULL来验证，如果建了索引但key是NULL，说明优化器放弃了。

解决办法有两个方向。一是覆盖索引：如果查询需要的字段全在二级索引里，就不用回表了。比如select name from user where name = 'abc'，name索引的叶子节点就有name值，直接返回。二是联合索引：把常用的过滤字段和返回字段组合进一个索引，也能实现覆盖。后面我会详细讲这两种手法的实操。

3.3 联合索引的物理排序与最左前缀

联合索引(a, b, c)在B+树里的排序规则是：先按a排序，a相同再按b排序，b相同再按c排序。这个“字典序”的排列方式直接推导出了最左前缀原则。

你可以把联合索引想象成一本书的目录，先按章节排，章节内按小节排，小节内按页码排。你要找“第3章第2节”，可以直接定位；但你没法跳过章节直接找“所有第2节”，因为第2节散落在各个章节里。同理，where b = 2用不上(a, b, c)索引，因为b在全局上不是有序的。

这里有个细节很多人搞混：where a = 1 and c = 3能不能用上索引？答案是能用上，但只能用a这一列。因为a确定之后，b是乱的，c在b乱的情况下也不是全局有序的。所以索引只能用来过滤a，c的部分要么靠索引下推在索引层过滤，要么回表后过滤。这个区分在面试里经常被考，答错了很掉分。

还有个更细的点：范围查询会截断后续列。where a = 1 and b > 2 and c = 3，索引能用上a和b，但c用不上。因为b是范围，在b的范围内c不是有序的。这个规则在MySQL 5.6引入索引下推（ICP）之后有所缓和——ICP可以在索引遍历阶段就用c来过滤，减少回表次数，但它不能把c变成索引查找的一部分。这个区别要讲清楚。

关于字段顺序怎么定，我给个实操原则：等值查询的列放前面，范围查询的列放后面，排序的列跟着来，最后考虑把select里常出现的列加进来做覆盖。比如一个查询是where user_id = ? and create_time > ? order by id，那索引可以设计成(user_id, create_time, id)。注意order by id没法用上索引，因为create_time是范围，后面的id不保证有序。如果要排序走索引，得把create_time换成等值，或者调整业务逻辑。

4. 索引失效与执行计划：面试最爱追问的实操环节

理论讲完了，面试官最喜欢在这里切换模式：“你平时怎么排查慢查询？”这个问题看似开放，其实是在验证你有没有真正用过explain、有没有调过索引。我的建议是准备一套固定的话术框架，把排查流程讲成一条线，而不是零散地蹦知识点。

我自己的排查顺序是这样的：先从慢查询日志里捞出具体的SQL，然后explain看执行计划，重点看type、key、key_len、rows、Extra这几列，判断是没走索引、走了但选择性差、还是走了索引但回表太多。接着看表结构和现有的索引，比对SQL的where条件和索引的最左前缀是否匹配，看看有没有函数、隐式转换这类会导致失效的写法。最后才是考虑改SQL、加索引、还是调整业务逻辑。

4.1 explain里必须盯紧的几个字段

explain输出的列不少，但真正决定判断的就这么几个。type列表示访问类型，从好到坏大致是：system>const>eq_ref>ref>range>index>ALL。生产环境里至少要看到range，如果出现index或者ALL，基本就是全表或全索引扫描，必须处理。index这个容易误解，它表示扫描整棵索引树，虽然比全表扫快一点（因为索引页更小），但数据量大了一样慢。

key列显示实际使用的索引，possible_keys是候选索引。如果possible_keys有值但key是NULL，说明优化器算完成本觉得不划算，放弃了索引。这种情况通常是因为索引选择性太差，或者回表成本太高。key_len表示用到的索引字节数，这个字段是判断“联合索引用了几列”的关键。rows是估算的扫描行数，虽然是估算值，但数量级有参考意义，如果估算出来和实际返回行数差了几个数量级，可能是统计信息过期，需要analyze table。

Extra列信息量最大。看到Using filesort说明排序没走索引，需要额外的排序操作；看到Using temporary说明用了临时表，常见于group by或者distinct；看到Using index是好消息，说明用了覆盖索引，没回表；看到Using index condition说明用上了索引下推；看到Using where则表示在存储引擎返回数据后，Server层还要再过滤一遍。这几个标记的组合能快速定位问题所在。

4.2 六种索引失效场景，附实测验证

下面这些场景我都实际建表验证过，不是从文档上抄的。你可以自己在测试库上复现一遍，印象会深得多。

第一种：左模糊或者全模糊匹配。where name like '%abc'用不上索引，因为B+树是按前缀有序的，你不知道开头是什么就没法定位。like 'abc%'是可以用上的。如果业务真的需要左模糊，考虑全文索引或者搜索引擎，别在MySQL里硬扛。

第二种：索引列上做函数运算。where date(create_time) = '2024-01-01'会让索引失效，因为要对每一行算完函数才能比较。改成where create_time >= '2024-01-01' and create_time < '2024-01-02'就能走范围索引。这个改法在日志类查询里特别常见，我几乎每次代码review都能看到几处。

第三种：隐式类型转换。字段是varchar，你传个数字where phone = 13800000000，MySQL会把字段值转成数字再比较，相当于在列上做了函数运算，索引失效。反过来，字段是int你传字符串，MySQL会把字符串转成数字，索引还能用。所以规则是：字符串字段一定要传字符串。这个坑在Java项目里尤其常见，因为参数类型不对编译器不报错。

第四种：or连接了非索引列。where a = 1 or b = 2，如果b没索引，整个查询就退化成全表扫描。哪怕a有索引也没用，因为要保证结果完整必须扫全表。解决办法是给b也加索引，或者用union all拆成两个查询。

第五种：不满足最左前缀。前面讲过，(a, b, c)索引下where b = 1用不上。这个不用多说，但要注意一种隐蔽情况：索引列的顺序和查询条件的顺序无关，where b = 1 and a = 2和where a = 2 and b = 1是一样的，优化器会自动调整。别在这上面纠结。

第六种：范围查询之后的列失效。前面讲过，where a = 1 and b > 2 and c = 3，c用不上索引查找。这个不算严格意义上的“失效”，但结果是一样的，值得单独记一笔。

4.3 覆盖索引、索引下推、MRR三件套

这三个优化手段是面试的高频加分项，理解它们能让你对索引的掌控力上一个台阶。

覆盖索引最直接。查询要的列全在索引里，就不需要回表。explain的Extra会显示Using index。实操上，把select *改成只查需要的字段，很多时候就能触发覆盖。我见过一个统计接口，原来select *扫了十万行回表，改成只查两个字段后走了覆盖索引，耗时从两秒多降到几十毫秒。当然，覆盖索引也不是免费的，它会让二级索引变大，写入成本上升，得权衡。

**索引下推（ICP）**是MySQL 5.6引入的。没有ICP的时候，联合索引(a, b)遇到where a = 1 and b like '%x%'，只能先用a把记录捞出来，然后全部回表，回表后再判断b。有了ICP，b的判断可以在索引遍历阶段就做掉，不合格的记录直接跳过不回表。Extra里显示Using index condition就是启用了。这个优化对联合索引里的模糊匹配、范围条件特别有效，能砍掉大量无效回表。

**MRR（Multi-Range Read）**相对冷门一些。它的思路是把二级索引扫出来的主键先收集起来，排序之后再批量回表。因为主键有序之后，回表的磁盘访问就从随机变成了近似顺序，对机械硬盘提升巨大，对SSD也有帮助。可以通过optimizer_switch里的mrr参数控制，默认是开的。面试里能提到这个，基本能证明你不是只看过入门文章。

5. 高频面试题速查与踩坑实录

到这里原理和实操都覆盖了，我整理一批实际被问过的题目，配上我自己的回答思路。这些题不是让你背标准答案，而是让你理解每道题在考哪个点，然后组织自己的语言。

5.1 常见问题速查表

关于深分页那道题，展开说一句。limit 1000000, 10这种写法会扫描前100万零10行然后丢掉前100万行，代价极高。优化思路有两个：一是延迟关联，先用覆盖索引查出主键，再关联原表；二是游标分页，记住上一页最后一条的id，用where id > last_id limit 10。第二种最适合无限下拉的场景，缺点是没法跳页。这个取舍要跟产品讲清楚，不是纯技术问题。

5.2 我实际踩过的几个坑

第一个坑是给低区分度字段建了单列索引。当时做一个消息表，想着“已读未读”查询频繁，就给is_read加了索引。结果这张表八百万行，未读消息只有几千条，已读的占了99%。查询已读列表的时候优化器直接放弃索引走全表扫，查询未读的时候虽然走了索引，但因为表设计里select了太多字段，回表次数多，反而不如直接扫。后来改成联合索引(user_id, is_read, create_time)，用user_id先把范围缩到单个用户，问题才解决。教训是：索引的选择性要结合查询条件看，单看一个字段的选择性没意义。

第二个坑是统计信息过期导致执行计划突变。有段时间线上一个查询突然变慢，SQL没改、索引没动，就是慢了。排查半天发现是表数据量在几天内涨了很多，统计信息没更新，优化器还以为只有几十万行，选了个错误的执行计划。手动analyze table之后恢复正常，后来加了定时任务定期更新统计信息。这个经历让我养成了看rows列和实际返回行数对比的习惯，差距大就先去更新统计信息。

第三个坑是字符集不一致导致join用不上索引。两张表关联，一张是utf8mb4一张是utf8，join的字段都建了索引，但explain显示type是ALL。原因是字符集不同，MySQL在比较前要做转换，相当于在列上做了函数运算。把所有表的字符集统一成utf8mb4之后问题消失。这个坑很隐蔽，因为两边单独查都正常，只有join的时候才出问题。

5.3 面试时怎么把答案讲出层次

同样的知识点，讲法不同效果差很多。我的建议是先给结论，再讲原理，最后落到你的实践。比如问“索引失效”，别一上来就罗列六种情况，先说“索引失效的本质是B+树的有序性被破坏了”，然后挑两三个最典型的展开，最后补一句“我在项目里遇到过xxx，当时是这么定位和解决的”。这个结构既显得有条理，又有真实感。

还有个小技巧：主动暴露边界。比如讲覆盖索引的时候，可以补一句“覆盖索引不是越多越好，索引列太多会让二级索引变大，写入成本上升，我们之前有个表索引列加太多，插入性能掉了三成，后来砍掉了一些”。这种话一说，面试官就知道你不是纸上谈兵。

6. 从面试题到生产实践：索引设计的落地方法

面试题刷得再熟，最终还是要落到怎么给一张真实的表设计索引。我给一套我自己在用的流程，你可以直接拿去套。

6.1 建索引前的四步判断

第一步，盘点查询。把这张表上所有的高频SQL列出来，包括点查、范围查、排序、分组。别只盯着当前的代码，也看看慢查询日志，很多历史遗留的烂SQL就藏在那里。

第二步，看区分度。对每个候选字段算一下count(distinct col) / count(*)，结果越接近1越好。低于0.1的字段单独建索引基本没意义，除非能和其他字段组合成高区分度的联合索引。

第三步，合并联合索引。多个单列索引往往可以合并。比如有where a = ?、where a = ? and b = ?、where a = ? order by b三种查询，一个(a, b)索引就能全部覆盖，比建两个单列索引更省。合并的时候按“等值在前、范围在后、排序跟着”的原则排字段顺序。

第四步，评估写代价。每加一个索引，插入、更新、删除都要多维护一棵B+树。写多读少的表要克制，一般控制在3到5个索引以内。加完索引后观察一段时间的写入延迟和磁盘增长，有异常就回退。

6.2 慢查询排查的固定套路

我习惯按这个顺序走，基本不会漏：

1. 从慢查询日志拿到具体的SQL和执行时间、扫描行数
2. explain看执行计划，重点看type是不是ALL或index，key是不是NULL，rows是不是明显偏大
3. 看show index from 表名，比对现有索引和SQL条件的匹配度
4. 如果是索引缺失，评估加索引的收益和写代价
5. 如果是索引存在但不生效，检查有没有函数、隐式转换、左模糊这类写法
6. 如果是索引生效但慢，看是不是回表太多，考虑覆盖索引或者调整查询字段
7. 改完之后用同样的数据量压测对比，确认真的有提升再上线

这套流程看着朴素，但能覆盖九成以上的慢查询场景。真正难的不是排查，是判断要不要改。有些查询慢是因为业务逻辑本身不合理，比如一次查十万条数据做导出，这种加索引也救不了，得改成异步任务分批处理。技术方案要跟着业务场景走，别为了优化而优化。

最后再分享一个小技巧，关于怎么记住这些知识。我发现单纯的文字记忆很容易忘，但如果你亲手在测试库上建一张百万行的表，把每种索引失效的场景都跑一遍，看着explain的结果从ref变成ALL，那个印象是刻在脑子里的。面试前与其翻笔记，不如花一个小时在本地跑一遍，效果会好得多。我自己到现在还保留着一个测试库，里面存着各种边界情况的表结构，遇到拿不准的写法就直接在上面试，比查文档快。