MySQL的联合索引遵循最左前缀匹配原则，当查询条件中出现Range类型的查询时，联合索引中该Range条件右侧的字段往往会无法被索引命中，这是很多慢查询产生的常见原因。理解这个现象的原理，并且掌握联合索引字段顺序的重构方法，能够有效提升数据库的查询性能。
Range查询导致右侧索引失效的原因
联合索引的存储结构是按照索引字段的顺序依次排序的，比如我们创建一个(a,b,c)的三字段联合索引，那么索引首先会按照a字段排序，a相同的记录再按照b排序，b相同的记录再按照c排序。
当查询条件中出现Range查询（比如>、<、BETWEEN、LIKE 'xxx%'这类范围查询）时，索引只能定位到Range条件对应的字段的起始位置，后续字段的排序顺序会被Range范围打乱，因此无法继续利用索引的有序性进行匹配，右侧的字段自然就失效了。
我们可以通过EXPLAIN命令来验证这个现象，首先创建测试表和联合索引：
-- 创建测试表
CREATE TABLE test_order (
id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT,
order_status TINYINT,
create_time DATETIME,
order_amount DECIMAL(10,2)
);
-- 创建联合索引 (user_id, order_status, create_time)
CREATE INDEX idx_user_status_time ON test_order(user_id, order_status, create_time);
-- 插入测试数据
INSERT INTO test_order(user_id, order_status, create_time, order_amount)
VALUES
(1, 1, '2024-01-01 10:00:00', 100.00),
(1, 2, '2024-01-02 10:00:00', 200.00),
(2, 1, '2024-01-01 11:00:00', 150.00),
(2, 2, '2024-01-03 10:00:00', 300.00),
(3, 1, '2024-01-02 12:00:00', 120.00);
执行包含Range查询的SQL，查看执行计划：
EXPLAIN SELECT * FROM test_order WHERE user_id = 1 AND order_status > 1 AND create_time = '2024-01-02 10:00:00';
执行结果中key_len只会包含user_id和order_status两个字段的长度，create_time字段并没有被索引使用，这就是Range查询后右侧索引失效的典型表现。
联合索引字段顺序的重构原则
要解决Range查询导致的右侧索引失效问题，核心是在设计联合索引时，把Range查询的字段尽量放在联合索引的末尾，让精确匹配的字段排在前面，这样Range字段右侧就不会有其他需要匹配的索引字段了。
重构联合索引字段顺序需要遵循以下三个原则：
- 精确匹配字段优先：等值查询的字段放在联合索引的最左侧，这类字段可以充分利用索引的有序性快速定位。
- Range查询字段靠后：范围查询的字段尽量放在联合索引的最后一位，避免其右侧存在其他索引字段。
- 高频查询字段优先：如果多个字段都是等值查询，那么区分度更高、查询频率更高的字段放在更左侧，提升索引过滤效率。
重构联合索引的实际案例
还是以上面的test_order表为例，假设我们的高频查询场景是：查询某个用户、某个状态范围、某个创建时间的订单，其中user_id是等值查询，order_status是范围查询，create_time是等值查询。
原来的索引(user_id, order_status, create_time)中，order_status是Range查询，右侧的create_time会失效。我们可以调整索引顺序为(user_id, create_time, order_status)，把Range查询的order_status放到最后一位。
重构索引的SQL如下：
-- 删除原来的索引 DROP INDEX idx_user_status_time ON test_order; -- 创建新的联合索引，调整字段顺序 CREATE INDEX idx_user_time_status ON test_order(user_id, create_time, order_status);
再次执行相同的查询语句，查看执行计划：
EXPLAIN SELECT * FROM test_order WHERE user_id = 1 AND order_status > 1 AND create_time = '2024-01-02 10:00:00';
此时key_len会包含user_id、create_time、order_status三个字段的长度，三个字段都被索引命中，查询效率会得到明显提升。
特殊情况说明
需要注意，LIKE 'xxx%'虽然是模糊查询，但属于前缀匹配的范围查询，同样会导致右侧索引失效，也需要放在联合索引的末尾。而LIKE '%xxx'或者LIKE '%xxx%'这类无法利用索引的有序性，无论放在什么位置都不会走索引。
另外如果查询中同时存在多个Range查询字段，那么只有第一个Range字段会生效，后续的Range字段都会失效，这种情况下需要评估业务场景，看是否可以把部分Range查询转换为等值查询，或者调整索引顺序让更重要的Range字段生效。
总结
MySQL联合索引中Range查询导致右侧字段失效的本质是范围查询破坏了后续字段的索引有序性，解决这个问题的核心是合理调整联合索引的字段顺序，把等值查询字段放前面，Range查询字段放最后。在实际开发中，我们需要结合业务的高频查询场景，先梳理每个查询条件的类型，再按照重构原则设计联合索引，最后通过EXPLAIN验证索引的使用情况，确保索引能够被充分利用。