MySQL索引从原理到实践：B+树、失效场景与联合索引设计

刚接手一个老项目的线上工单，慢SQL一条接一条地刷出来，查看执行计划后数据扫描量直接到千万级，不少核心表压根没建索引，把整个应用拖得奄奄一息。这种问题很常见，尤其是团队里对MySQL索引的理解还停留在“查询慢就加个索引”的直觉层面，没有真正搞懂索引在底层做了什么、什么情况加了等于白加、什么时候反而会拖慢写入。这篇就当是这些年踩坑后做的系统梳理，从数据结构一路讲到EXPLAIN和联合索引设计，适合刚接触索引的开发者，也适合准备面试时把细节补全。

1. 为什么一条慢SQL能把整个接口拖垮：索引到底在加速什么

很多教程一上来就解释B+树，却没说清楚一个最根本的问题：没有索引的时候，数据库执行查询到底在做什么？搞明白这一点，后面所有对索引的理解都有支撑。

1.1 没有索引时，MySQL在闷头扫全表

InnoDB存储引擎的数据是存在磁盘上的，磁盘里最小的读写单位是页，默认一页16KB。数据行就存在这些页里，一个页放不下就往下一个页放。当你执行一条没有索引条件的查询时，比如：

sql复制SELECT * FROM member WHERE phone = '13800138000';

如果phone列没有索引，InnoDB只能从第一个数据页开始，把整张表的每一个页都读出来，再逐行判断phone字段是否匹配。这个过程叫全表扫描，想绕都绕不开。

我们来粗略算一笔账。假设member表有1000万行，平均每行长度100字节，那么一个16KB的页大约可以放160行。1000万行除以160行，大概需要62500个页。全表扫描就要处理6万多个页的数据，即使利用顺序读的预读机制，在千万级数据量的场景下也足够让接口耗上好几秒。

全表扫描的代价还有一个隐藏点：它对内存的冲击很大。InnoDB的缓冲池是有限的，一次大范围扫描会把很多热点数据页挤出去，后面其他查询再想读这些被挤走的热数据页，就又要去磁盘搬一遍。所以一条慢SQL不只是自己慢，还会连累整个实例上所有查询的命中率，这就是一条烂SQL拖垮一个库的根本原因。

1.2 加了索引之后，查找路径完全变了

索引能干的事情，本质上是把“逐页逐行扫描”变成“按路径直接定位”。这里用查字典来类比很贴切：没有目录时你要从第一页翻到最后一页，有了目录你就能先找拼音或偏旁，一个页面一个页面跳转，最终直接落到目标那一页。

InnoDB的索引是B+树结构，主键索引会把整张表的数据按照主键顺序组织成树。一个千万级数据量的表，主键索引树通常只有三层左右。查询一条记录时，从根节点出发，一层层往下走，大概经历三次磁盘IO就能到达叶子节点，叶子节点里存的就是完整的数据行。三次IO和执行几万次页扫描的差距，已经不在同一个量级了。

这也是为什么面试和实际开发都这么看重索引。在数据量小时，全表扫描可能也就几十毫秒，索引的优势不明显；一旦表数据量过了百万千万级别，索引就是决定接口能不能在几百毫秒内返回的关键。

1.3 索引同样加速排序和分组

除了过滤数据，索引还承担着减少排序成本的职责。B+树的叶子节点天然是有序的，如果你查询时用到的ORDER BY字段正好有索引，MySQL可以直接沿着索引顺序读取数据，不需要额外生成临时文件做filesort。

举一个实际例子：

sql复制SELECT id, amount FROM pay_order WHERE status = 1 ORDER BY create_time DESC LIMIT 20;

如果(create_time)上有索引，这个排序可以走索引完成；如果没有，MySQL需要先把status = 1的所有结果查出来，再放到sort buffer里做一次整体排序。当结果集很大时，排序还要落盘，速度会非常慢。GROUP BY也有类似逻辑，分组操作的第一步往往也是排序。所以索引不只是给WHERE服务的，给排序和分组加分同样重要。

2. InnoDB的B+树：索引物理形态与“回表”到底在回什么

了解了索引在宏观上做了什么，还得钻进去看看索引到底长什么样。很多索引优化做不好，都是因为对B+树的组织方式和回表机制的理解模模糊糊。

2.1 为什么偏偏是B+树，而不是哈希表或红黑树

如果把数据结构摊开对比，选择B+树的原因就更清晰了。

哈希表在等值查询上确实逆天，一次哈希计算就能定位数据，时间复杂度O(1)。但哈希表有两个硬伤：一是完全无法处理范围查询，你没法让哈希表告诉你“大于100且小于200”的所有记录在物理上怎么连续；二是哈希值是无序的，天然不支持排序。偏偏日常业务里范围查询和排序又非常频繁，比如时间区间、金额区间、分页这种写法到处都是，所以哈希索引只能作为辅助。

红黑树这类二叉平衡树呢？等值和范围查询都能做，但每个节点只能存一个键值，数据量大了以后树的高度会非常高。你可以在脑子里想象一下20层和3层的差距：每下一层就意味着可能产生一次磁盘IO，IO次数越高查询越慢。

B+树的聪明之处在于它的节点不是只存一个键，一个节点就是整整一页数据。每个节点内部可以放成百上千个键值对，这样一来，同样存储千万行数据，树的高度可以控制在3到4层。范围查询时，B+树的叶子节点之间还维护了双向链表，找到起点之后顺着链表一路往后遍历就行。这几个特性合在一起，让B+树成为关系型数据库索引的默认选择。

2.2 聚簇索引与二级索引，回表到底在回什么

InnoDB中，表数据本身就是按照主键构建的B+树组织的，这棵树叫聚簇索引树。它的叶子节点直接存储完整的数据行。这意味着只要你通过主键查数据，B+树找到叶子节点的那一刻，整行数据已经在手上了，不需要额外访问其他地方。

但日常查询常常不会只走主键，更多时候是通过某个业务字段查询，比如phone、email。这时我们会在这些字段上建立二级索引（也叫辅助索引或普通索引）。二级索引也是一棵B+树，只是它的叶子节点存储的不是完整数据行，而是这条记录对应的主键值。

问题来了：当查询条件是phone，但你想SELECT出整个member表的多个字段时，MySQL会先在phone二级索引树上找到phone值对应的主键ID，然后拿着这些主键ID再到主键聚簇索引树里查一次完整的数据行。这个拿二级索引查到主键、再到主键索引取数据的过程，就叫回表。

回表本身不是坏事，它是InnoDB的常规操作。但回表属于随机IO，一次回表就要访问一次聚簇索引树，如果结果集很大，回表成本会特别高。所以覆盖索引的思路就出现了：如果二级索引的叶子节点已经包含了你要查询的所有字段，MySQL就不需要回表了。比如只在phone列上建了索引，现在执行：

sql复制SELECT phone FROM member WHERE phone = '13800138000';

由于二级索引的键值就是phone本身，查询过程在二级索引上已经拿到了mysql需要的phone值，不需要再回表。而当二级索引包含多个列时，如索引(phone, name)，执行SELECT phone, name也只需要从索引读取。EXPLAIN里的Extra列会出现Using index，就代表这次查询使用了覆盖索引，没有回表。

2.3 主键为什么要尽量避免随机值

理解了聚簇索引的叶子节点就是数据本身后，也就理解了为什么强烈推荐用自增主键。

自增主键是顺序递增的，新插入的数据会追加到当前索引页末尾附近，页分裂和索引碎片很少发生。如果主键是UUID这类随机字符串，问题就来了：一个UUID字符串作为主键，每次插入的位置是随机散布的，插入时为了让B+树保持有序，MySQL要不断调整页内的记录位置，当目标页已经满了的时候，还会把页进行拆分腾出空间，造成大量碎片和额外IO。

我在自己做过的压测里，UUID主键和自增主键写入性能差距相当明显，B+树要处理的页分裂会让写放大，页的利用率下降后索引体积也会膨胀。因此在MySQL 8.0的InnoDB里，绝大多数场景都应该用BIGINT UNSIGNED自增作为主键，实在需要在业务层生成ID的，也建议采用雪花算法这种趋势递增的方案，而不是纯粹的随机字符串。

提示：如果一张表没定义主键，InnoDB会优先选择一个非空唯一索引作为聚簇索引；如果也不存在，则InnoDB会生成一个隐藏的6字节自增rowid当主键。总之聚簇索引一定存在，只是隐藏rowid无法被你主动利用。

3. 常用的几类索引：从建表开始把语法和适用场景一次理清

索引不是一种东西，它有好几种形态。你可能见过“主键索引”“唯一索引”“普通索引”“全文索引”“前缀索引”“联合索引”这些名词，它们的定位和使用方式各不相同。对一个入门者来说，把它们放在一起区分开，是最容易省时间的。

3.1 各个索引类型和建索引语法

先给出一张总表，后面代码演示就按这张表来：

建表或建索引的几种写法：

sql复制CREATE TABLE member (
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键',
    phone VARCHAR(20) NOT NULL COMMENT '手机号',
    email VARCHAR(100) DEFAULT NULL COMMENT '邮箱',
    name VARCHAR(50) NOT NULL COMMENT '姓名',
    age INT DEFAULT NULL COMMENT '年龄',
    PRIMARY KEY (id),
    UNIQUE KEY uk_phone (phone),
    KEY idx_name (name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='会员表';

如果表已经建好，可以用ALTER TABLE或者CREATE INDEX补索引：

sql复制ALTER TABLE member ADD INDEX idx_name (name);
ALTER TABLE member ADD UNIQUE INDEX uk_email (email);
CREATE INDEX idx_age ON member(age);

这里简单提一句索引命名的约定：普通索引用idx_前缀，唯一索引用uk_前缀，后面跟字段名。线上环境索引数量多了以后，命名规范真的能救命，否则一排idx_name、idx_age还好，真到了联合索引idx_a_b_c这种程度，如果没有约定，时间一长连你自己都分不清哪个索引是干嘛的。

3.2 前缀索引：省空间和区分度的平衡

字符串字段建索引的麻烦在于，如果字段非常长，索引体积会非常大。比如email字段，正常长度三四十个字符，做索引时其实没有必要存整个字符串，B+树的键值会庞大很多，占用更多空间和IO。

MySQL提供了前缀索引，只取字符串前若干个字符作为索引键：

sql复制ALTER TABLE member ADD INDEX idx_email_prefix (email(10));

前缀索引的关键在于选取合适的前缀长度。取得太短，区分度太低，查询时扫出来的候选集太多，索引优势不显著；取得太长，则空间节省有限。可以用下面这条SQL来评估不同前缀长度的区分度：

sql复制SELECT
    COUNT(DISTINCT LEFT(email, 8)) / COUNT(*) AS prefix_8,
    COUNT(DISTINCT LEFT(email, 10)) / COUNT(*) AS prefix_10,
    COUNT(DISTINCT LEFT(email, 12)) / COUNT(*) AS prefix_12
FROM member;

比例接近1时，说明前缀长度基本能代表整个字段。通常选择区分度维持在0.9以上的最短长度，兼顾空间和查询精度。要注意，前缀索引有代价：它无法用于覆盖索引，而且排序场景基本用不上，因为索引只存了部分字符。

3.3 唯一索引那些不得不防的边界

唯一索引最常见的坑是很多人误以为“允许NULL就代表可以重复”，这是大错特错。MySQL唯一索引对NULL的处理规则是：NULL值不参与唯一性判断，所以同一列可以有多个NULL。比如member表的email列建了唯一索引，100条记录email全为NULL也完全合法。如果业务上要求“邮箱要么为空、要么全局唯一”，需要在应用层做兜底判断，或者用生成列的方式处理。

另一个坑是，业务上要保证某个字段唯一，但数据里已经存在大量重复值，此时建唯一索引会直接报错。线上拆这个问题的常规方法是先把重复数据处理干净，再建索引，而不是用ALTER TABLE IGNORE这种老掉牙的方式去静默删除数据。我在生产环境见过因为建唯一索引失败导致整个上线流程卡住的场景，所以线上加唯一索引前，一定要先用分组统计把存量重复数据查清楚。

3.4 FIND_IN_SET这种写法能吃上索引吗

搜索词里经常出现“findinset能走索引吗”，这是一个很有代表性的问题。如果一列里存的是逗号分隔的ID串，比如1,2,3，然后用FIND_IN_SET('1', column)去查，这个写法几乎不可能走索引。

原因是B+树索引要求查询条件能对索引键值做前缀匹配或等值匹配，而FIND_IN_SET的工作逻辑是遍历字符串内容做子串分析，索引无从帮忙。真实业务里这种逗号串存储的设计非常普遍，但如果你需要在列表页做这类查询，就别指望加索引能解决，更合理的做法是把这种多值字段拆成关联子表，一行存一个关联关系，再对子表的字段建普通索引。这样等值查询可以用索引，效率完全不是一个量级。

4. 索引失效的五种典型写法：代码评审时我会重点盯这些

很多开发都能说出一堆索引失效的场景，但一到实际写SQL又踩坑。整理一下我在代码评审和线上问题排查里见到最多的五类写法。它们共同的特点是：索引确实建了，但因为写法问题，MySQL无法利用索引定位，优化器只能选择全表扫描。

4.1 对索引列使用函数或表达式计算

假设member表有注册时间字段register_time，并且上面建了索引。如果业务想查“2024年1月1日注册的会员”，最常见的错误写法是：

sql复制SELECT * FROM member WHERE DATE(register_time) = '2024-01-01';

当WHERE条件对索引列套了函数之后，这个函数作用于索引列的值，等于是要把每个日期值都先经过一次DATE函数处理才能和右边的常量比较。B+树里存储的是原始值，没法直接按这个计算后的结果做定位，优化器只能放弃索引。正确写法是给出明确的范围区间：

sql复制SELECT * FROM member
WHERE register_time >= '2024-01-01 00:00:00'
  AND register_time < '2024-01-02 00:00:00';

这样区间内的B+树有序结构就能被充分利用。不光是DATE，对索引列做四则运算也一样，比如WHERE id + 1 = 100，MySQL不会帮你把表达式反转成id = 99，它会老实扫描全表。

4.2 隐式类型转换引发的索引失效

这是特别容易忽视的一种。member表的phone列是VARCHAR类型，查询时如果写：

sql复制SELECT * FROM member WHERE phone = 13800138000;

右边是一个整数，MySQL对类型不一致的比较会做隐式类型转换。问题在于转换的方向是把字段转成数值类型来做比较，相当于在索引列上执行了CAST(phone AS SIGNED)，这会让phone列上的索引失效。

判断自己有没有踩这个坑，最简单的办法是查看表结构里字段是字符型还是数值型，写WHERE条件时保证两边类型一致。上面这条SQL把手机号加上引号写成'13800138000'即可。我在审查代码时经常看到有人从接口参数里直接取值拼接SQL，参数是整数就拼整数，这很容易触发隐式转换，所以ORM框架尽量用参数绑定而不是字符串拼接，也能规避一部分风险。

4.3 LIKE通配符放在开头的模糊匹配

“SELECT * FROM member WHERE name LIKE '%张%'”这种包含式模糊匹配，在MySQL里很难走索引。B+树的数据是按前缀有序排列的，当匹配条件以%开头时，优化器根本不知道目标值在树的哪个区间，只能遍历所有记录做匹配。

如果需求变成了“查询所有姓张的人”，也就是前缀匹配写法：

sql复制SELECT * FROM member WHERE name LIKE '张%';

这时B+树完全可以利用字符串的前缀有序性，定位到第一个“张”字开头的记录，然后向后顺序扫描，索引就能被利用。对包含式匹配的需求，除非数据量很小，否则不建议在MySQL里硬扛。可以选用专门的全文搜索引擎，或者考虑MySQL全文索引、ES等外部方案。

4.4 OR条件连接了非索引列

WHERE条件里用了OR也很容易让索引失效。比如：

sql复制SELECT * FROM member WHERE phone = '13800138000' OR age = 20;

phone列上有索引、age列上没有索引。当优化器面对这个条件时，它无法只走phone索引就得到全部结果，因为age = 20的记录可能散落在全表任何位置；但如果不走phone索引全表扫描，至少能一次性把两个条件都过滤完。多数情况下优化器会选择全表扫描，于是phone索引就废了。

解决思路有几种：如果业务允许，把OR改成两次结果合并；或者把两列建一个联合优化结构，让查询能利用到索引的多个条件；在数据量可控时也可以使用UNION ALL把phone查询和age查询的结果合并起来。实际工作中，OR条件多起来时我一般会重新审视查询场景，必要时拆成两个SQL，而不是依赖一条复杂SQL走天下。

4.5 NOT IN、!= 以及IS NOT NULL的坑

索引失效的第五类高频场景是负向查询。B+树擅长等值查找和范围查找，而NOT IN、NOT LIKE、!=这类条件本质上要排除一堆值，优化器通常评估下来全表扫描更划算。

更有迷惑性的是IS NOT NULL。MySQL官方文档里对IS NULL的规则是：如果列上有索引，IS NULL条件是可以走索引的，但IS NOT NULL很可能被优化器判断为全表扫描。这是因为NULL在B+树中的处理方式与其他值不同，NULL值在索引中聚集在一边，IS NULL可以快速定位，而IS NOT NULL则需要访问绝大多数数据。

对这些负向查询，我见过能提升性能的通用思路是改写为正向查询范围，或者通过冗余字段、状态位等方式避免大范围的负向判断。一个典型的例子是逻辑删除场景：

sql复制-- 不推荐，deleted=1表示已删除，大范围NOT IN
SELECT * FROM pay_order WHERE order_status IN (1,2) AND deleted != 1;

更好的做法是把“已删除”标志位设计成有效记录为0、无效记录为正数，然后查询时用等于某个固定状态来过滤，至少查询条件变成了正等值匹配，再用部分索引或字段分区也能继续优化。

5. 索引下推：MySQL 5.6之后默认开启的隐性加速

“mysql索引下推是指什么”是搜索词里出现频率极高的问题，同时也是面试官爱考、实际优化中又容易被忽视的点。索引下推的英文是Index Condition Pushdown，简称ICP，是MySQL 5.6引入的优化，在5.6之后默认开启。它解决的问题是：利用联合索引减少不必要的回表次数。

5.1 没有索引下推之前会白白回表多少次

假设member表上有一个联合索引(idx_name_age)，索引列顺序为(name, age)。执行以下查询：

sql复制SELECT * FROM member WHERE name LIKE '张%' AND age = 20;

在MySQL 5.6之前，存储引擎通过联合索引找到所有以“张”开头的记录，拿到这些记录主键后逐个回表，再从这些完整数据行里判断age是否等于20。假设表里姓“张”的记录有10万条，但age=20的记录只有200条，这意味着有99800次回表是白白浪费的——它们回表之后马上就被age条件过滤掉了。

千万级的表遇到这种查询，回表风暴很容易造成磁盘IO飙升。这正好解释了为什么两个字段都在同一个联合索引上、SQL看起来也很规范，查询却仍然慢得离谱，因为引擎没有把过滤条件贯彻到底，提前从索引阶段剔除不符合条件的记录。

5.2 索引下推把过滤动作下推到存储引擎

ICP的核心思路是，对于联合索引中已经包含的过滤条件，在遍历索引的过程中直接判断，筛选出完全满足条件的记录后才回表。存储引擎层在读取索引记录时，同时检查age = 20是否满足，满足的才回表取完整数据，这样就大大减少了回表次数。

依然是上面的查询，在开启索引下推后，服务器会把name LIKE '张%' AND age = 20这个条件中与索引列相关的部分下推到存储引擎。存储引擎读取索引记录时同时校验两个条件，真正回表的只有age=20的那200条记录。回表次数从10万降到200，查询耗时自然下降了几个数量级。

提示：索引下推并不需要改写SQL，它是由MySQL优化器自动决定的。判断当前查询有没有走ICP，只需看EXPLAIN的Extra列中是否出现Using index condition。

5.3 为什么有索引下推，联合列顺序仍然要慎重

ICP让联合索引的使用更加宽容了，但绝不是说“索引列顺序随便建都行”。有一个原则依然是：经常用于等值判断的列尽量放左边，范围条件列放右边。原因是对于范围条件之后的列，MySQL无法直接利用B+树的有序性做定位，即使ICP能在索引遍历时辅助过滤，它也不是通过树查找完成的。

比如索引(name, age)，查询条件是name LIKE '张%' AND age = 20。name上的LIKE是一个范围条件，到了age这里，B+树已经无法再利用age做精确定位了，但在ICP帮助下仍然能在索引扫描过程中过滤age。这种属于“能过滤但不算查找”的状态。如果反过来把age放左边、name放右边，查询age = 20 AND name LIKE '张%'时，age做等值定位后，在age确定的叶子节点范围内，name的模糊前缀仍然可以继续利用索引有序性去遍历，效果会比第一种更好。所以联合索引的列顺序还是要围绕实际查询场景来思考，ICP只是一个兜底优化，不应当成为随意设计列顺序的借口。

6. 用EXPLAIN把脉索引：别再只盯着结果发呆

很多新手发现SQL慢之后，连EXPLAIN都没用过就直接加索引，加完发现没用再来问为什么。实际判断索引到底走没走、走了几个、有没有回表，最可靠的依据就是执行计划。MySQL提供的EXPLAIN命令能显示优化器选择的执行路径，学会看它，才算真正看懂了SQL。

6.1 EXPLAIN的核心列：type、key、rows、Extra

对一条SQL执行EXPLAIN，会得到很长一串列。对面试和绝大多数日常排查来说，比较重要的是type、key、rows、Extra这几列。

type列表示访问类型，从好到差大致是：

rows列是优化器估算的需要扫描的行数，这个数字越小越好。但它只是估算，不一定准确。key列显示实际选中的索引，如果为NULL就说明没走任何索引。

Extra列也有大量信息。出现Using index表示覆盖索引，不需要回表；出现Using index condition表示使用了索引下推；出现Using where表示存储引擎返回结果后在Server层又做了条件过滤；出现Using filesort则意味着查询出现了额外的排序操作，需要重点看排序字段是否可以利用索引。

6.2 key_len的计算逻辑决定你到底用到了联合索引的几列

联合索引字段可能很多，EXPLAIN显示的key是整个联合索引的名字，光看key列你不知道具体用了哪几列。这时候要看key_len，它表示本次查询中实际使用的索引字节长度。通过计算key_len，就可以反推出联合索引走了哪些列。

以utf8mb4字符集为例，常见类型和NULL标记的长度对应关系：

• INT类型：4字节
• BIGINT类型：8字节
• VARCHAR(n)：n乘以4加2字节变长长度，再加1字节允许NULL标记占用
• CHAR(n)：n乘以4加1字节允许NULL标记占用
• DATETIME：5字节（MySQL 5.6+）

举一个example。假设联合索引idx_name_age(name VARCHAR(50) NOT NULL, age INT NOT NULL)，如果EXPLAIN显示key_len为202，计算方式是name字段50*4+2=202，说明只用到了name列；如果key_len是206，则202再加age的4字节，说明两列都用上了。

我这里顺手编一个对比：索引idx_phone_email(phone VARCHAR(11) NOT NULL, email VARCHAR(100) DEFAULT NULL)，那么phone的key_len=114+2=46，email的key_len=1004+2+1=403。如果执行计划里看到key_len=46，表示只用了phone，没有继续用email。这个信息对排查联合索引是否走完整非常关键，我经常靠它直接抓出“明明建了联合索引但某个查询只用了最左边一列”的问题。

6.3 为什么同一个SQL的EXPLAIN结果会不一样

“explain 结果不同”这种情况是真实的，不要在排查时惊掉下巴。MySQL优化器决定走哪个索引，并不是看SQL文本是否一样，而是看它基于表统计信息估算出来的代价。

数据分布变化会直接影响优化器判断。举个例子，member表sex字段只有“男”“女”两个值，区分度极低，你在sex上建了索引，查询WHERE sex = '男'时优化器大概率会放弃索引走全表。原因很简单：索引定位和回表的成本加在一起，比直接全表扫描还高。可如果sex的值越来越分散，比如出现了10个不同取值，优化器对同一个SQL的EXPLAIN结果就可能变道索引扫描。

另外，表的统计信息是否更新也会影响执行计划。InnoDB通过采样估算索引基数，长时间大量增删改后统计信息可能滞后。可以用ANALYZE TABLE来强制更新统计信息。如果执行计划还是不理想，可以尝试在SQL里用FORCE INDEX(索引名)强制指定索引。但FORCE INDEX属于临时手段，根本解法还是优化SQL写法或者调整索引结构去适配查询。

7. 联合索引设计：最左前缀规则与真实业务取舍

联合索引是实际项目里最常用、也最容易出错的索引形态。一个联合索引往往能覆盖多个查询场景，比单独建多个单列索引更省空间，但也引入了一条重要规则：最左前缀。

7.1 最左前缀规则其实强调的是一种能力组合

在联合索引(a, b, c)上，实际相当于同时对下面几种查询情况提供支持：

• 只使用列a的查询
• 使用列a和列b组合的查询
• 使用列a、b、c三者组合的查询
• 使用列a和列c（跳过了b）的查询，能走索引但中间b的索引范围会限制c无法精确定位

当查询条件不包含最左边的a列，而是直接WHERE b = ? AND c = ?时，MySQL无法利用这个联合索引。记住这一点后，很多疑惑都会迎刃而解。它就像一本先按拼音、再按笔画编排的字典，如果你只提供了笔画而不提供拼音，就没法在目录里定位。

最左前缀规则同时也决定了ORDER BY的利用方式。如果索引是(a, b)，那么ORDER BY a是能走索引的，ORDER BY a, b也能走索引，但ORDER BY b单独排序走不上。范围条件之后的排序字段也可能产生filesort，这个要结合具体SQL去分析。

7.2 设计联合索引的顺序：等值条件优先、区分度高优先

聊完基础规则，来看实际设计。假设业务上有这么几张高频查询：

• 商家后台查某个会员的手机号、姓名、年龄
• 运营侧查某个年龄区间的会员数量
• 注册时间倒序分页查会员

我们很容易想到为member表设计一个联合索引。一般顺序可以按以下策略思考：

1. 先找出查询中最常见的等值条件列，把它们放最左边，因为等值条件能最大化利用B+树的定位能力。
2. 等值条件都排完之后，范围条件放中间或后面，比如年龄区间、注册时间区间。范围之后的列基本无法继续做精确定位。
3. 若多个字段都是等值条件，则优先把区分度更高的字段放前面，这样索引在每一层都能较快收窄范围。
4. 根据最左前缀规则，看看这个联合索引是否还能覆盖其他高频查询。如果多个查询都以a列开头，那么(a, b, c)这种设计通常好过单独建(b, c)。

不妨假装member表上常见的查询条件组合是phone、age、status。优先参与排序设计：

sql复制KEY idx_phone_status_age (phone, status, age)

意思是，先按phone等值定位，再按status等值过滤，最后如果在范围内还需要age字段过滤或排序，也能在索引上继续处理。如果某次查询只需要phone和age，即使status在中间被跳过，最左前缀能力也能走到phone列，age列的利用视status是否为范围条件而决定。这个细节需要结合EXPLAIN的key_len去观察。

7.3 索引不是越多越好：冗余索引和写入成本

设计索引时最容易犯的另一个错误是一味追求“哪条查询慢就加一条索引”。实际中如果把使用频率很低的索引建了一堆，不仅占空间，还会明显拖慢INSERT、UPDATE、DELETE的速度。因为每次写入都要同时维护多个B+树，索引越多，写放大越严重。

冗余索引是需要清理的重灾区。比如表里已有联合索引(a, b)，后来又单独加了索引(a)。由于联合索引(a, b)已经足够支撑只查a的查询，那个单独的(a)索引就是冗余的，完全可以删除。可以用下面的SQL查看一张表上所有索引信息：

sql复制SHOW INDEX FROM member;

然后人工分析各索引的前缀列是否与其他索引完全重合。发现(a)和(a, b)同时存在时，直接删掉短的那个通常没问题。

7.4 一次联合索引调整的真实收益

我自己接手过一个支付对账表，表里几千万行，日增几十万。原来查询条件是商户号、对账日期、状态，三个字段分别建了三个单列索引。执行老SQL时，优化器只能选其中一个最优索引，然后对结果集做回表，再用另外两个条件过滤。每天的对账任务要跑十几分钟，线上抖动也很频繁。

后来把三个字段调整成一个联合索引(merchant_id, bill_date, status)，通过等值字段merchant_id先定位，bill_date做范围条件缩小，status在范围内过滤，并把核心查询改成只查必要列以命中覆盖索引。调整后，对账时间从十几分钟降到几十秒，写入性能也因为删掉了多余单列索引没有明显恶化。这类收益在数据量起来后会非常明显。

作为一个还在摸索阶段的开发者，你可能暂时不需要设计千万级表的索引，但这些原则越早建立越有价值。每次写完一条新SQL，先EXPLAIN扫一眼，看看type是不是ALL、rows是不是大得离谱、Extra有没有filesort，多问一句“这里到底是扫描了一万行还是定位到了三行”。把这种习惯变成肌肉记忆后，你写出来的SQL天然就会少很多坑，线上数据库也会用稳定性能回馈你。