MySQL 组合索引怎么选列顺序：等值、范围与排序的执行边界

给订单列表加索引时，很多人会把“经常出现在 WHERE 里的字段”按想到的顺序拼起来，结果索引建了，慢查询却没有明显改善。组合索引真正要回答的是：查询先用哪些条件缩小范围，在哪个条件之后会失去连续扫描能力，以及排序是否还能沿着同一棵索引完成。

先用一个订单查询看差别

假设后台按租户、状态和创建时间查看订单，常见 SQL 是：

SELECT id, user_id, amount, created_at
FROM orders
WHERE tenant_id = 18
  AND status = 'paid'
  AND created_at >= '2026-08-01'
ORDER BY created_at DESC
LIMIT 50;

这个查询同时包含两个等值条件、一个时间范围和排序。比起分别为三个字段建单列索引，更值得先验证 (tenant_id, status, created_at) 这样的组合是否能让扫描从一个租户和状态的小区间开始。

列顺序先按条件类型拆开

第一步看条件是否是等值。tenant_id = 18 和 status = 'paid' 能把索引入口固定到更窄的区间，因此通常放在范围列之前。第二步看范围条件，created_at >= ... 会把扫描变成一段连续区间；它后面若再放其他定位字段，通常不能像前面的等值列一样继续切分入口。

这不是“所有等值列都必须排在最前”的机械规则。还要把真实查询组合放进来：如果另一条高频查询只有 tenant_id 和 created_at，而没有 status，就要比较它是否值得单独设计索引，不能只为一条 SQL 追求最长索引。

什么时候排序可以顺便完成

当过滤条件固定了索引前缀，并且排序列紧接在后面时，MySQL 有机会按索引顺序返回结果，减少额外排序。例如上面的组合索引在租户和状态都为等值条件时，创建时间位于连续区间内，降序读取前 50 行通常更自然。

但如果查询改成按金额排序，或者状态变成范围条件，索引仍可能用于过滤，却不一定能同时消除排序。看到 Using filesort 不应马上判定索引失效：要结合返回行数、排序成本和是否能接受覆盖索引一起判断。

用 EXPLAIN 验收而不是凭感觉

验证时先建立候选索引，再用与线上一致的参数执行：

CREATE INDEX idx_orders_tenant_status_created
ON orders (tenant_id, status, created_at);

EXPLAIN SELECT id, user_id, amount, created_at
FROM orders
WHERE tenant_id = 18 AND status = 'paid'
  AND created_at >= '2026-08-01'
ORDER BY created_at DESC LIMIT 50;

重点看四项：key 是否选中候选索引，key_len 是否反映使用到的列，rows 是否比原计划明显下降，Extra 是否出现了预期之外的临时表或大范围扫描。不同数据分布下结果可能不同，测试表必须接近生产的租户规模、状态比例和时间跨度。

三个容易踩到的边界

• 字符串前缀、函数表达式和隐式类型转换，可能让列无法按普通索引方式定位。
• 组合索引列过多会增加写入和缓存压力，不能把所有筛选字段都塞进去。
• 优化器会根据统计信息选择计划；数据量变化后要重新观察，而不是永久相信一次 EXPLAIN。

如果查询只是偶尔执行，优先确认它是否真的值得增加索引；如果是高频分页列表，则要把过滤、排序、返回列和深分页成本放在同一次验收里。

常见问题

是不是选择性最高的列永远放第一？

不一定。查询是否经常使用该列、是否与其他条件形成稳定前缀，往往比单独统计的选择性更重要。先按高频查询形状设计，再用实际计划验证。

范围列后面的字段完全没用吗？

不是完全没用。它们可能参与覆盖、索引条件下推或其他计划细节，但通常不能像范围列之前的等值字段那样继续缩小最初的连续扫描入口。

看到 Using filesort 就一定要改索引吗？

不一定。少量结果排序可能比维护一棵更宽的索引更划算。先比较实际耗时、扫描行数和写入代价，再决定是否为排序列调整索引。

组合索引的列顺序最终由“查询如何缩小范围、哪里出现边界、结果如何排序”共同决定。把候选方案放进真实数据的 EXPLAIN 和慢查询样本里，才能知道它是在减少工作，还是只是增加了一棵看起来合理的索引。