在mysql的查询优化场景中，联合索引的顺序直接决定了索引能否被有效利用，错误的顺序可能导致全表扫描或者索引部分失效，影响查询效率。联合索引遵循最左前缀匹配原则，理解这个原则是优化顺序的基础。
联合索引的最左前缀匹配原则
联合索引是将多个列组合成一个索引，查询时只有从索引的最左列开始匹配，才能使用到这个联合索引。比如我们创建了(a,b,c)的联合索引，那么只有查询条件中包含a，或者a和b，或者a、b、c的组合时，才能命中这个索引。如果查询条件直接从b开始，那么这个联合索引就无法被使用。
常见的最左匹配场景示例
假设我们有用户表user，包含id、age、city、name四个字段，我们创建联合索引idx_age_city_name (age,city,name)，以下是不同查询条件的命中情况：
- 查询条件
age=20：可以命中联合索引，使用索引的第一列 - 查询条件
age=20 and city='北京'：可以命中联合索引，使用索引的前两列 - 查询条件
age=20 and city='北京' and name='张三'：可以命中联合索引，使用全部三列 - 查询条件
city='北京'：无法命中联合索引，不符合最左前缀原则 - 查询条件
name='张三' and age=20：mysql优化器会自动调整条件顺序，依然可以命中联合索引
联合索引顺序的优化原则
1. 优先把区分度高的列放在最左
区分度指的是列中不同值的数量占总行数的比例，区分度越高，过滤效果越好。比如user表中city只有10个不同值，age有100个不同值，那么age的区分度更高，应该放在联合索引的更左侧。这样查询时第一列就能过滤掉大部分数据，减少后续列的匹配范围。
我们可以通过以下sql计算列的区分度：
-- 计算age列的区分度 SELECT COUNT(DISTINCT age) / COUNT(*) AS age_distinct_ratio FROM user; -- 计算city列的区分度 SELECT COUNT(DISTINCT city) / COUNT(*) AS city_distinct_ratio FROM user;
2. 优先把查询频率高的列放在最左
如果某个列在where条件中出现的频率远高于其他列，那么应该把这个列放在联合索引的最左侧，这样可以让更多的查询命中联合索引。比如业务中大部分查询都会带city条件，那么即使city的区分度不高，也应该把city放在联合索引的最左位置。
3. 范围查询的列尽量放在联合索引的右侧
联合索引中，如果某一列使用了范围查询（比如>、<、BETWEEN、LIKE 'xxx%'之外的LIKE），那么这一列右侧的所有列都无法使用索引。所以范围查询的列应该尽量放在联合索引的靠右位置，减少索引失效的范围。
比如查询age>20 and city='北京' and name='张三'，如果联合索引是(age,city,name)，那么age是范围查询，后面的city和name都无法使用索引；如果联合索引是(city,name,age)，那么city和name可以使用索引，age作为范围查询列放在最右，不会影响到前面的列。
4. 考虑排序和分组的列顺序
如果查询中包含ORDER BY或者GROUP BY子句，那么联合索引的顺序可以和排序、分组的列顺序保持一致，避免额外的排序操作。比如查询WHERE city='北京' ORDER BY age，那么创建(city,age)的联合索引，既可以命中where条件，又可以满足排序需求，不需要额外进行filesort操作。
联合索引顺序优化示例
假设我们的user表有以下查询场景：
- 高频查询1：
WHERE age=20 AND city='北京' AND name LIKE '张%' - 高频查询2：
WHERE city='北京' ORDER BY age - 低频查询3：
WHERE name='张三'
我们先分析各列的情况：
| 列名 | 区分度 | 查询频率 |
|---|---|---|
| age | 0.8 | 高 |
| city | 0.1 | 高 |
| name | 0.9 | 低 |
首先高频查询1中name是LIKE '张%'属于范围查询，应该放在最右侧；高频查询2需要city和age的顺序和联合索引一致，同时city查询频率高，所以优先考虑city在最左，然后是age，最后是name，因此联合索引顺序为(city,age,name)。
我们验证这个索引的效果：
-- 创建联合索引 CREATE INDEX idx_city_age_name ON user(city,age,name); -- 验证高频查询1，使用EXPLAIN查看执行计划 EXPLAIN SELECT * FROM user WHERE age=20 AND city='北京' AND name LIKE '张%'; -- 执行结果中key会显示idx_city_age_name，说明命中索引 -- 验证高频查询2 EXPLAIN SELECT * FROM user WHERE city='北京' ORDER BY age; -- 执行结果中Extra没有Using filesort，说明排序使用了索引
验证联合索引顺序是否生效
优化完联合索引顺序后，我们需要通过EXPLAIN命令验证索引是否被正确命中，重点关注以下几个字段：
key：显示实际使用的索引，如果是我们创建的联合索引，说明命中成功key_len：显示使用的索引长度，长度越长说明使用的索引列越多Extra：如果有Using index说明使用了覆盖索引，Using where说明使用了where过滤，没有Using filesort和Using temporary说明没有额外排序和临时表
如果key显示为NULL，说明没有命中索引，需要重新检查联合索引的顺序是否符合最左前缀原则，或者查询条件是否和索引顺序匹配。
注意事项
联合索引的顺序不是固定不变的，需要根据实际的业务查询场景动态调整。如果业务查询模式发生了变化，比如原来高频查询city，现在高频查询age，那么需要重新评估联合索引的顺序。同时不要创建过多的联合索引，每个联合索引都会占用额外的存储空间，并且会影响插入、更新、删除操作的性能，需要在查询性能和写入性能之间做好平衡。