索引顺序是MySQL联合索引设计中最容易被忽视的一环。不少开发者以为只要把查询条件里的几个列都塞进一个联合索引，优化器就能自动安排好一切，实际上索引列的先后顺序直接决定了这个索引能不能被使用、能被使用到什么程度。本文从最左前缀原则讲起，结合范围查询、排序场景和常见设计误区，把索引顺序这件事说透。
最左前缀原则：索引顺序的核心规则
MySQL的联合索引本质上是一棵B+树，索引项的排序方式是先按第一列排序，第一列相同时再按第二列排序，依此类推。这就好比电话本先按姓氏排、同姓再按名字排——如果你想找所有姓王的人，直接翻到王姓区域即可；但如果你想找所有叫“伟”的人，就只能翻遍整本电话本。联合索引的存储结构决定了它只能支持从最左列开始的连续匹配。
举个例子，假设有这样一个索引：
-- 建立联合索引 idx_a_b_c ALTER TABLE t_order ADD INDEX idx_a_b_c (a, b, c); -- 能完整或部分使用索引的查询 SELECT * FROM t_order WHERE a = 1 AND b = 2 AND c = 3; -- 三列都用上 SELECT * FROM t_order WHERE a = 1 AND b = 2; -- 用到 a、b SELECT * FROM t_order WHERE a = 1; -- 只用到 a SELECT * FROM t_order WHERE a = 1 AND c = 3; -- 只用到 a，c 无法走索引 -- 完全无法使用索引的查询 SELECT * FROM t_order WHERE b = 2; SELECT * FROM t_order WHERE b = 2 AND c = 3;
可以看到，跳过第一列直接查询后面的列，索引就彻底失效了。而a = 1 AND c = 3这种写法虽然第一列匹配了，但第三列因为中间隔了一列，索引在c这一层是无序的，只能通过回表或索引条件下推去过滤，效果大打折扣。理解了这一点，就能明白为什么索引顺序“有影响”——它影响的是索引能覆盖查询条件的范围。
范围查询之后，索引列会失效
联合索引还有一个容易被忽略的细节：一旦某一列使用了范围条件（大于、小于、BETWEEN、LIKE前缀匹配以外的模糊查询等），排在其后的列就无法继续走索引了。原因同样是B+树的排序机制——范围查询会让索引定位在一个区间内游走，此时后面的列在区间内是乱序的，无法再用二分定位。
-- 索引 idx_create_time_status (create_time, status) -- create_time 是范围条件，status 用不上索引 SELECT * FROM t_order WHERE create_time > '2024-01-01' AND status = 2; -- 调整为 idx_status_create_time (status, create_time) -- status 等值匹配后，create_time 的范围查询仍可走索引 SELECT * FROM t_order WHERE status = 2 AND create_time > '2024-01-01';
上面的例子体现了索引顺序设计的一条重要经验：等值条件的列放在前面，范围条件的列放在后面。两种索引在数据量大时性能差距可能是数量级的。可以通过EXPLAIN命令查看执行计划，重点关注key_len字段——它反映了索引实际被使用的字节数，如果key_len明显小于索引定义的总长度，说明有列没被用上。
索引顺序如何服务于排序和分组
除了WHERE条件，索引顺序还影响ORDER BY和GROUP BY能否利用索引的有序性避免额外排序。如果索引的列顺序与ORDER BY的列顺序一致，且方向一致（都是升序或可利用降序索引），MySQL可以直接按索引顺序扫描，省去filesort这个开销不小的步骤。
-- 索引 idx_a_b (a, b) -- 可以利用索引避免排序 SELECT * FROM t_order WHERE a = 1 ORDER BY b; -- 无法利用索引完整排序，需要 filesort SELECT * FROM t_order WHERE b = 2 ORDER BY a; SELECT * FROM t_order ORDER BY b, a;
一个典型的业务场景是“按用户查看其订单列表，按时间倒序分页”，查询类似WHERE user_id = ? ORDER BY create_time DESC LIMIT 10。这种查询就应该建(user_id, create_time)的联合索引，而不是给user_id和create_time各建一个单列索引。后者看似覆盖了条件，实际上排序环节还是要额外的排序操作，数据量大时分页性能会急剧下降，甚至出现深分页超时。
索引设计的其他注意事项
顺序之外，还有几条经验值得遵守。首先是区分度问题：单独为性别、状态这类只有几个取值的列建索引意义不大，优化器很可能因为扫描比例过高而放弃使用。但把它们作为联合索引的第一列，配合后面的高区分度列，往往是合理的，比如(status, create_time)用于定时任务扫描特定状态的记录。
其次是控制索引数量。每个索引都是一棵独立的B+树，写入时都要同步维护，索引过多会让INSERT、UPDATE、DELETE明显变慢，还占用磁盘空间。一般建议单表索引控制在5个左右，冗余索引（如已有(a, b)又建(a)）应当删掉。
最后注意隐式类型转换和函数操作导致索引失效的问题。字符串列与数字比较时MySQL会做隐式转换，此时索引失效；对索引列使用函数或参与运算同样会导致无法走索引：
-- phone 是 varchar 类型 SELECT * FROM t_user WHERE phone = 13800138000; -- 索引失效 SELECT * FROM t_user WHERE phone = '13800138000'; -- 正常走索引 SELECT * FROM t_order WHERE DATE(create_time) = '2024-01-01'; -- 索引失效 SELECT * FROM t_order WHERE create_time >= '2024-01-01' AND create_time < '2024-01-02'; -- 改写后可走索引
总结
索引顺序对查询性能的影响是实实在在的：它决定了索引能否命中、能覆盖到哪一列、能否免去额外排序。设计联合索引时，遵循“最左前缀原则、等值列在前范围列在后、排序列紧跟等值列”这几条思路，再结合实际的查询语句逐条核对，用EXPLAIN验证执行计划，就能避免大多数索引设计上的坑。索引不是越多越好，贴合查询才是最好的设计。