在数据库优化的江湖里流传着这样一个让人抓狂的故事：你满怀信心地给一张大表加上了精心设计的联合索引，心想这下查询速度肯定要起飞了。结果，现实狠狠地给了你一巴掌——查询速度不仅没变快，甚至有时候比以前还慢，geng气人的是用 EXPLAIN 一kan，数据库压根就没理睬你那个引以为傲的索引，直接来了个全表扫描。

这时候，你可Neng会盯着屏幕怀疑人生：难道我建了个假索引？其实这hen可Neng是因为你踩中了数据库索引里Zui经典、也Zui容易让人掉坑的一个规则——联合索引的顺序问题。今天咱们就抛开那些晦涩难懂的官方文档，像老朋友聊天一样，彻底把这事儿掰扯清楚。

一、 联合索引到底是个什么鬼？

hen多刚入门的朋友容易把联合索引想象成简单的“把几个字段捆在一起”。虽然从表面上kan确实是这样，但在数据库底层，它的逻辑可比这复杂得多，也精妙得多。

咱们先别急着背公式，先来想象一个生活中的场景。假设你手里有一本厚厚的纸质

Ru果你要找“王二小”，这hen简单，你先翻到“王”姓的那一叠，然后在这一叠里找名字叫“二小”的。这hen快，对吧？

现在Ru果我们把这个

这时候，Ru果你想找“所有叫小明的人”，不管他姓什么你Neng直接翻到那一页吗？

绝对不Neng！

因为

回到数据库，联合索引 的底层B+树结构，就是先按 a 字段排序，a 相同的时候，再按 b 字段排序。Ru果你在查询条件里直接跳过 a 去查 b，数据库就会像那个找“小明”的人一样，一脸懵圈，只Neng放弃索引，乖乖去扫全表。

二、 Zui左前缀原则：不可逾越的红线

上面那个

简单来说你的 WHERE 条件必须像爬楼梯一样，从联合索引的Zui左边那一列开始，一阶一阶往上爬，不Neng跳级。

假设我们有一个联合索引 ，这就像是一个三层抽屉柜：

第一个抽屉： 必须先打开。Ru果你没告诉数据库你要找哪个职业，后面的抽屉是锁死的，打不开。

第二个抽屉： 只有当你确定了第一个抽屉里的内容，这个抽屉才有序排列，才Neng快速查找。

第三个抽屉： 同理，前两个确定了这个才Neng发挥作用。

所以Ru果你的查询是 WHERE age = 25 AND status = 1，哪怕 age 和 status dou在索引里数据库也会两手一摊：对不起，profession 没给，我找不到路。

但是这里有个hen有意思的细节。Ru果你只查 WHERE profession = '程序员'，这是Ke以的，这叫“用了索引的一部分”；Ru果你查 WHERE profession = '程序员' AND status = 1，虽然中间跳过了 age，但只要 profession 用上了status 在部分数据库引擎里其实还是Neng蹭上一点索引的，只不过效率不如全字段匹配那么高罢了。但Zui核心的一点千万别忘：Zui左边的那个列，绝对不Neng丢！

三、 顺序的艺术：等值、范围与排序的博弈

好，既然知道了不Neng跳过Zui左列，那Ru果我有好几个列dou要用，它们的内部顺序怎么排呢？是 还是 ？

这可不是掷骰子决定的，这里面有着严格的逻辑。这里我送大家两条在实战中摸爬滚打出来的“铁律”。

铁律1：等值查询的列放前面范围查询的列放后面

什么叫等值？就是 =，精确匹配。什么叫范围？就是 BETWEENLIKE 'abc%' 这种。

为什么要把等值的放前面？因为等值查询Neng瞬间把数据锁定在一个极小的范围内，就像狙击手一样精准。而范围查询，哪怕范围hen小，它本质上也是一段连续的数据。

想象一下你建了索引 。

查询语句是：WHERE user_id = 123 AND order_date> '2023-01-01'。

数据库的执行过程是这样的：它先利用 user_id = 123 快速定位到这个用户的所有订单数据。然后因为 order_date 在这个范围内是有序的，数据库只需要从这个位置开始，往后一直找，直到日期不满足条件为止。这非常高效。

反过来Ru果你把索引建成了 ，再用同样的 WHERE user_id = 123 AND order_date> '2023-01-01' 去查。

灾难发生了。数据库先按 order_date 找到了大于1月1日的数据，这时候发现这里面混杂着成千上万个不同用户的订单。虽然 user_id 也在索引里但因为前面的 order_date 是范围查询，破坏了 user_id 的有序性，数据库就没法继续利用索引树往下走了只Neng把找出来的数据一个个拿去回表判断。

记住一句话：一旦遇到了范围查询，后面的字段索引基本就废了。 所以要把那个Neng帮你把范围缩到Zui小的“等值”字段放在Zui前面当排头兵。

铁律2：Ru果有排序，把排序列放在Zui后

hen多时候，我们查询不仅要筛选，还要排序，比如 ORDER BY create_time DESC。

Ru果索引顺序安排得好，数据库在取出数据的时候，天然就是排好序的，直接返回就行，这叫“Using index”，省去了内存排序和文件排序的开销，速度飞快。

怎么Zuo到？把排序列放在索引的Zui后。

比如查询：WHERE user_id = 123 AND status = 1 ORDER BY order_date DESC。

Zui佳索引：。

逻辑是这样的：先定 user_id，再定 status，剩下的数据自然就是按 order_date 排列的。数据库直接按顺序读20条就完事了根本不需要额外的排序动作。

Ru果你把 order_date 放在中间，比如 ，那数据库在处理完 status 筛选后发现顺序乱了还得重新在内存里排一次序，白白浪费CPU资源。

四、 实战复盘：拯救一条慢查询

光说不练假把式。前两天我就遇到了这么个事儿，拿出来给大家复盘一下kankan这理论是怎么落地的。

场景是这样的：我们有一个订单表 orders，数据量大概在1000万左右。业务方反馈，说查询某个用户的“Yi完成”订单，按时间倒序列表，特别慢，有时候甚至超时。

原来的SQL长这样：

SELECT * FROM orders 
WHERE user_id = 12345 
  AND status = 'Yi完成' 
ORDER BY order_date DESC 
LIMIT 20;

当时表上只有一个索引：idx_user_id 。

我们来kan一下执行计划：

type: ref rows: 5000 Extra: Using where; Using filesort

kan到那个 Using filesort 了吗？这就是罪魁祸首。数据库先通过 user_id 找到了5000条订单，然后把这5000条数据全部加载到内存里因为 status 没索引，得一条条过滤；过滤完剩下的，再因为 order_date 没索引，得重新排序。这一顿操作下来CPU不爆才怪。

优化思路：

根据咱们前面说的“铁律”： 1. user_id 是等值查询，放Zui前。 2. status 也是等值查询，放中间。 3. order_date 是排序字段，放Zui后。

于是我果断执行了这条DDL：

ALTER TABLE orders 
ADD INDEX idx_uid_status_date ;

建完索引之后奇迹发生了。再kan执行计划：

type: ref rows: 20（注意，这里直接定位到了Zui终需要的20行！) Extra: Using index condition

那个讨厌的 Using filesort 不见了！查询时间从几百毫秒直接降到了几毫秒。这就是联合索引顺序正确的威力。

五、 那些容易被忽视的“坑”

除了顺序，还有几个小细节，Ru果不注意，索引也会莫名其妙地失效，这里顺带提个醒。

1. 区分度太低的字段别当头

有些同学喜欢把 is_deletedgender这种字段放在联合索引的Zui前面。千万别这么干！

为什么？因为Ru果你把 is_deleted 放第一位，数据库一查，发现全表一半的数据dou是0，这时候索引就失去了“快速定位”的意义，它会觉得“还不如直接扫表呢”，于是直接放弃索引，导致 type: ALL。这种字段，要么别放索引，要么就放在联合索引的后面配合覆盖索引使用。

2. 统计信息不及时

有时候你明明建对了索引，但数据库就是不用。这可Neng是因为数据库的“统计信息”过时了。数据库是根据统计信息来预估每个索引有多少行、成本是多少的。Ru果统计信息还是几年前的，它可Neng会误判。

在Oracle里你可Neng需要手动跑 analyze table；在MySQL里通常比较自动，但Ru果遇到这种情况，也Ke以尝试 ANALYZE TABLE table_name 来geng新一下。不过记得，这玩意儿挺耗资源的，Zui好在系统闲的时候干。

3. 隐式转换

这个坑Zui隐蔽。比如你的字段是字符串类型的 phone，你查询时写成了 WHERE phone = 13800000000。数据库会偷偷地把字段转换成数字，或者把数字转换成字符串。这一转换，索引就废了。一定要保证类型匹配！

六、 ：别让努力白费

写了这么多，其实核心就那几句话。联合索引不是简单的字段堆砌，它是一把严格按照顺序排列的瑞士军刀。

记住这几个口诀：

等值前列，范围后排，排序列收尾，覆盖带上SELECT。

建索引之前，多花一分钟kankan你的 WHERE 和 ORDER BY。顺序错了索引就是摆设，甚至还会拖累写入性Neng；顺序对了它就是性Neng提升的核武器。

别再让“白费功夫”的悲剧发生了。下次再遇到慢查询，先别急着加硬件，先kankan你的联合索引顺序是不是搞反了。希望这篇文章Neng帮你避开那些我曾经踩过的坑，让你的SQL飞起来！我是小耶，一个在代码和数据库之间摸爬滚打的记录者，咱们下期见！

---