MySQL 组合索引列顺序怎么配合范围条件和排序

MySQL 组合索引列顺序不能只按“区分度最高的列放最前面”来决定。带有等值条件、范围条件和排序的列表查询，通常应先放能形成稳定左前缀的等值列，再放范围列；但如果排序是主要目标，也要检查排序列能否继续沿索引连续读取。范围条件一旦出现，后续列通常不能再像等值列那样继续缩小索引查找区间，最终是否省掉排序和回表必须用 EXPLAIN确认。

先把查询写成索引左前缀

假设订单列表固定按租户和状态筛选，只查看最近一段时间，并按创建时间、订单号倒序展示：

-- 先固定租户和状态，再限定时间窗口，最后稳定排序
CREATE INDEX idx_order_list
ON orders (tenant_id, status, created_at DESC, id DESC);

-- 典型列表查询：等值条件在左侧，时间是范围，id 用来稳定同秒排序
SELECT id, status, created_at, total_amount
FROM orders
WHERE tenant_id = 18
  AND status = 'paid'
  AND created_at >= '2026-08-01 00:00:00'
  AND created_at 

(tenant_id, status, created_at, id)的左侧先把一个租户下的已支付订单聚在一起，然后进入创建时间区间。若把时间放在第一列，租户和状态就无法形成同样紧凑的左前缀；若把 id 放到时间前面，查询又不能直接沿创建时间顺序取数。MySQL 官方文档把多列索引解释为拼接后的有序键，并明确只有左前缀可用于查找。

范围条件之后，索引还能做什么

“最左匹配”容易被误读成范围列后面的字段完全无效。更准确的说法是：范围列先确定一段索引区间，后续列通常不能再把这个区间切成和等值谓词一样精确的查找边界。它们可能参与索引条件检查、覆盖读取或排序判断，但不能保证继续缩短 key_len 对应的有效查找前缀。

排序也不是“索引里有这个列就一定不用排序”。如果排序列不连续、使用了另一棵索引，或者排序表达式不是索引列本身，MySQL 仍可能执行 filesort。对于 LIMIT 30 的列表，能否直接从合适的索引顺序拿到前 30 行，往往比盲目追求覆盖索引更重要。

排序列和覆盖列要分开权衡

组合索引末尾加入返回列，有机会让查询只读索引，不再回表取订单金额等字段；但索引越宽，写入、更新和缓存占用也越高。下面两种索引服务的目标不同：

-- 只优先服务筛选与排序，适合返回列很多的列表
CREATE INDEX idx_order_page
ON orders (tenant_id, status, created_at DESC, id DESC);

-- 只在查询稳定且返回列少时考虑覆盖；金额字段会增加索引维护成本
CREATE INDEX idx_order_page_cover
ON orders (tenant_id, status, created_at DESC, id DESC, total_amount);

InnoDB 二级索引记录还带有主键值，所以 id常能承担稳定排序和定位作用；这不表示任意 SELECT *都会覆盖。用 SELECT明确列出需要的字段，再比较 rows、响应延迟和写入负担，才知道覆盖索引是否值得。

函数表达式要么改写，要么建立一致的表达式索引

下面的写法把函数施加在列上，普通的 created_at 索引未必能直接按年份定位：

-- 函数包住列，普通 created_at 索引难以直接使用年份边界
SELECT id, created_at
FROM orders
WHERE YEAR(created_at) = 2026;

-- 将年份条件改写成原列的半开区间，保留时间列的顺序性
SELECT id, created_at
FROM orders
WHERE created_at >= '2026-01-01 00:00:00'
  AND created_at 

MySQL 8.4 的 CREATE INDEX支持 functional key part，但表达式必须使用额外括号，并受生成列规则限制。查询表达式要和索引表达式保持一致；例如索引按 SUBSTRING(col, 1, 10)建立，查询写成长度 9 的表达式就不能期待相同的索引匹配。表达式索引不是给所有函数调用的补丁，先确认业务是否真的按该表达式筛选，再评估维护成本。

用 EXPLAIN 看范围、排序和回表是否符合预期

不要因为执行计划显示了索引名就认为设计完成。先保留一条代表性查询，再看以下字段：

-- 用 JSON 计划保留更多优化器信息，便于比较不同索引
EXPLAIN FORMAT=JSON
SELECT id, status, created_at, total_amount
FROM orders
WHERE tenant_id = 18
  AND status = 'paid'
  AND created_at >= '2026-08-01 00:00:00'
  AND created_at 

• key：优化器实际选了哪棵索引；为空不代表“所有索引都不行”，还要看成本。
• key_len：用于判断有效使用到哪些索引前缀，不能机械按列数换算。
• rows：估算需要检查的行数；统计信息陈旧时，先考虑 ANALYZE TABLE orders。
• Extra：出现 Using filesort表示发生了额外排序；没有它也不等于一定覆盖，仍要核对返回列和回表。

MySQL 官方文档说明，EXPLAIN展示优化器如何执行语句，ORDER BY优化章节则把 Using filesort作为判断额外排序的线索。生产调整时先在接近真实数据分布的环境比较计划，不要仅凭一张小表的估算行数删除或新增索引。

常见问题

组合索引是不是一定要把区分度最高的列放第一位？

不是。先保证高频查询的等值左前缀、范围位置和排序目标，再在这些候选中比较选择性与写入成本。

范围列后面的排序列还有意义吗？

有可能有意义，但不能保证继续过滤。是否能免掉 filesort取决于固定列、范围形状、排序列连续性、方向和优化器成本。

看到 Using filesort 就必须改索引吗？

不一定。小结果集的内存排序可能比扫描宽索引再回表更便宜，应结合 LIMIT、rows、返回列和真实延迟判断。

函数索引和生成列应该选哪一个？

只要查询表达式稳定且需要直接按表达式过滤，可以考虑 functional key part；如果还要复用表达式值、调试字段或跨版本迁移，则显式生成列通常更容易管理。

索引设计的落点不是背一条列顺序口诀，而是把一个真实查询拆成等值前缀、范围起点、排序连续性和返回列四件事，再用 EXPLAIN逐项核对。每新增一棵索引，也要把插入、更新、空间和统计信息维护成本一起算进去。