当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL 组合索引怎么选列顺序：等值、范围与排序的执行边界

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

来源：17golang原创 2026-08-24 10:14:39 0浏览收藏

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

要点速览

组合索引列顺序应先看查询形状，再看单列基数。
等值条件通常放在范围条件前，便于继续缩小连续扫描区间。
范围条件可能成为索引利用的边界，后续列未必还能同时用于定位。
最终用 EXPLAIN 的 key、key_len、rows 和 Extra 验收，不凭索引名称猜效果。

先用一个订单查询看差别

假设后台按租户、状态和创建时间查看订单，常见 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 是否出现了预期之外的临时表或大范围扫描。不同数据分布下结果可能不同，测试表必须接近生产的租户规模、状态比例和时间跨度。