联合索引的顺序:写错等于白建(最左前缀+范围条件+覆盖索引详解)

简介: 本文讲透联合索引核心——最左前缀原则、等值/范围列排序逻辑、ORDER BY优化及覆盖索引技巧,附真实慢查优化案例,助你建对索引、秒懂原理!

我是小耶,干运营半路出家的野生DBA——写功课只是为了我踩过的坑,你们别再踩了!


刚学数据库的时候,我知道联合索引可以给多个字段一起建索引。但我一直搞不懂一个问题:

为什么明明建了 (order_date, user_id),用 user_id 查的时候,索引还是不走?

后来才知道,联合索引的顺序是有讲究的。顺序错了,等于白建。


一、什么是联合索引?

你把联合索引想象成一个​电话本​。

电话本的排序规则是:先按姓氏排,再按名字排。比如“王小明”排在“王小刚”前面,因为姓相同,再看名。

联合索引也一样。如果你建了 (a, b),那它会把数据先按 a 排,a 相同再按 b 排。

那么你想查“所有叫小明的人”,能直接翻到那一页吗?不能,因为电话本没有按“名”排,只能一页页翻。这就是为什么 WHERE b = ... 用不上 (a, b) 索引——b 相当于“名”,不是第一排序依据。

结论:查询条件里,必须包含索引的最左列 ,索引才会生效。

这就是 ​最左前缀原则​。


二、最左前缀原则

联合索引 (a, b, c) 可以当成三个索引来用:

  • 一个只按 a 排的索引
  • 一个按 a, b 排的索引
  • 一个按 a, b, c 排的索引

但你不能把它当成 (b, c)(c) 来用。因为跳过了最左列,索引就废了。

规则​:

  • WHERE a = 1 ✅ 走索引(用了第一列)
  • WHERE a = 1 AND b = 2 ✅ 走索引(用了前两列)
  • WHERE a = 1 AND b = 2 AND c = 3 ✅ 走索引(全用)
  • WHERE a = 1 AND c = 3 ⚠️ 只用到 ac 用不上(因为跳过了 b
  • WHERE b = 2 ❌ 不走索引(没从最左列开始)

三、怎么做?确定联合索引顺序的两条铁律

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

什么叫等值?WHERE user_id = 123,就是等值。
什么叫范围?WHERE order_date > '2026-01-01'> 就是范围。

如果你写 WHERE user_id = 123 AND order_date > '2026-01-01',索引应该建 (user_id, order_date)

为什么?因为 user_id 等值,可以精确定位到某一组数据;然后在这个组里,order_date 是有序的,范围查询只需要沿着这个有序列表往后找。

反过来建 (order_date, user_id)order_date 范围查询后,user_id 的等值就无法在索引里用了,因为后面的列在遇到范围后就失效。

铁律2:如果有 ORDER BY,把排序的列放在最后

假设查询是 WHERE user_id = 123 ORDER BY order_date
(user_id, order_date) 索引,既能快速过滤 user_id,又能让 order_date 天然有序,排序就不用临时做 filesort,快很多。


四、实际案例:优化一条慢查询

场景​:订单表几百万行,我要查用户123的“已完成”订单,按订单日期倒序,只要前20条。

原SQL:

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

原索引​:只有 (user_id)

执行计划:type=refrows=5000(这个用户有5000条订单),Extra=Using where; Using filesort(因为 status 没索引,要回表过滤;order_date 没索引,要额外排序)。

优化过程​:

  1. 等值条件有 user_idstatus,两个都是等值 → 放前面
  2. 排序列 order_date → 放最后
  3. 希望不回表(覆盖索引)→ 把 SELECT 需要的列也加进去

最终建索引:

ALTER TABLE orders ADD INDEX idx_uid_status_date (user_id, status, order_date);

再查:type=refrows=86(因为 status 帮索引过滤掉了大部分数据),Extra=Using index condition(索引下推,没有 filesort),速度从几百毫秒降到几毫秒。

价值​:同样的查询,加对索引后快了几十倍。


五、你一定会遇到的几个坑

错误写法 为什么错 正确做法
WHERE a > 1 AND b = 2,建索引 (a, b) 范围 a 放左边,b 等值失效 建索引 (b, a)
WHERE a = 1 AND c = 3,建索引 (a, b, c) 跳过 bc 用不上 如果 b 没有条件,可以建 (a, c) 或调整查询
ORDER BY b 但索引是 (a, b),且 a 无等值条件 不满足最左前缀,ORDER BY 用不上索引 建索引 (b) 或给查询加 a 条件

六、总结

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

建索引之前,先问自己三个问题:

  • WHERE 里哪些是等值?(放最左)
  • 有没有范围查询?(放右边)
  • 有没有 ORDER BY?(放最后,或考虑覆盖索引)

把这几点搞明白了,你不光能建对索引,还能解释给别人听。

小耶在手,SQL不愁。

你遇到过“建了联合索引还是慢”的情况吗?

相关文章
|
3月前
|
关系型数据库 MySQL 测试技术
JOIN、IN、EXISTS谁最快?实测三种写法性能差异与执行计划深度剖析
本文用MySQL 8.0实测拆解`IN`/`EXISTS`/`JOIN`子查询性能:从执行计划、半连接优化、临时表开销等底层原理出发,结合10万+100万数据实测(`EXISTS`最快95ms),给出三条选型铁律——告别盲从“最佳实践”,只选最适配业务与数据的写法!
|
4月前
|
SQL 数据库 数据库管理
写完SQL先别跑,这两步能救你一晚
我是小耶,专注踩坑与填坑,今天分享SQL性能关键:数据库执行顺序(FROM→WHERE→…)与人脑思维的错位——切忌先JOIN后过滤!用实例对比,教你“过滤前置”提速技巧。养成自查习惯,SQL轻松快一倍!
|
3月前
|
SQL 关系型数据库 MySQL
MySQL慢查询诊断实战:从10秒到0.1秒,我的5步排障法
数据库小学妹分享慢查询优化实战:从10秒降至0.08秒!详解「发现→收集→分析→优化→验证」5步排障法,覆盖慢日志配置、EXPLAIN进阶、索引失效场景、JOIN与分页优化等核心技巧,附真实案例与速查表。
|
3月前
|
SQL 关系型数据库 MySQL
MySQL主从复制实战:从原理到读写分离,新手避坑全指南
数据库小学妹带你轻松入门主从复制!✅基于binlog实现主库写、从库读,支撑读写分离与高可用;🛡️保障数据安全(灾备)、提升并发能力;🔧详解三种复制模式、搭建步骤、延迟优化及避坑指南。运维进阶必备!
|
2月前
|
SQL 存储 关系型数据库
覆盖索引:让你的查询直接从索引返回,彻底告别回表
覆盖索引是SQL优化中性价比较高的技巧,让查询直接从索引返回所需列,避免回表操作。本文解释覆盖索引的原理,通过EXPLAIN的“Using index”判断是否生效。结合复合索引设计、深分页优化(延迟关联)等场景,给出覆盖索引的使用方法和注意事项。用好覆盖索引,不改SQL逻辑,仅调整索引设计即可显著提升查询性能。
|
4月前
|
安全 Java 程序员
python进程、线程、协程
multiprocessing是python的多进程管理包,和threading.Thread类似。
230 4
|
4月前
|
弹性计算 安全 关系型数据库
阿里云特惠云服务器99元和199元1年新购续费同价:配置、适用场景与专属组合套餐解析
阿里云推出的99元1年和199元1年新购续费同价云服务器因价格实惠、性能适中,深受个人和普通企业用户的喜爱。99元经济型e实例适合个人开发者等搭建轻量级应用;199元通用算力型u1实例则能稳定支持中小型企业官网等场景。此外,阿里云还提供建站礼包、安全防护、弹性数据库、高效存储及多场景组合套餐等专属优惠,并构建了一个丰富、灵活、高性价比的云产品生态,助力用户无忧上云、轻松降本。
|
3月前
|
算法 关系型数据库 MySQL
【MySQL】MySQL的海量数据处理六大方案:分库分表、读写分离、分片策略、跨库事务、扩容方案、Sharding-JDBC中间件
本文系统梳理MySQL海量数据处理六大核心方案:读写分离、垂直/水平分库分表、分片策略选型、分布式事务(2PC/TCC/Saga等)、平滑扩容实践及Sharding-JDBC中间件应用,兼顾性能、一致性与可扩展性,助力架构稳健演进。
|
3月前
|
SQL 缓存 数据库
你还在用LIMIT 1000000,10?献上分页查询优化技巧
本文详解“深分页”陷阱:`LIMIT 1000000,10`为何慢?3种优化方案(游标法、子查询定位、延迟关联)实测提速数十倍,助你零成本提升SQL性能!