MySQL 联合索引中间列范围条件为什么影响后列

MySQL 联合索引遇到中间列的范围条件时，后列不是“完全失效”，但通常不能再把扫描范围缩成一个连续区间。原因在于 B-Tree 按整组键值排序：例如索引 (tenant_id, created_at, status) 中，tenant_id=7 先固定了前缀，created_at>='2026-01-01' 再形成一段范围；这段范围里不同 status 会交错出现，后列就难以继续定义单一连续区间。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

联合索引其实是一串有序键组

把联合索引想成按元组排序的数组更容易理解。索引 (tenant_id, created_at, status) 先比较租户，再比较时间，最后比较状态。只有前面的比较结果已经固定，后面的值才会在一个连续片段里有序排列。

因此，等值条件能把搜索锚点钉在某个前缀；范围条件只能给出一段区间。区间内部仍保留后列信息，却不保证后列对应的记录集中在一起。图中的“键组区间”表达的是访问边界，“剩余过滤”表达的是完整 WHERE 还要检查的条件，两者不要混为一谈。

适用压力：中间列一旦放宽，后列为什么不再连续

看一个典型查询：

-- 用租户等值和创建时间范围查订单，状态是额外业务条件
SELECT id, status, created_at
FROM orders
WHERE tenant_id = 7
  AND created_at >= '2026-01-01'
  AND status = 'paid';

在原索引下，优化器可以围绕 (7, '2026-01-01', -∞) 到相应上界建立键组区间。状态为 paid 的记录并不会在时间范围里天然相邻，所以 status='paid' 常表现为范围扫描后的过滤条件。这个结论描述的是连续 range 的边界，不是说 status 从索引中消失。

如果后列同时出现在索引中，MySQL 仍可能借助索引条件下推减少回表，或者因为查询只读取索引列而获得覆盖效果；是否发生要看实际执行计划，不能只凭列顺序下结论。

用 EXPLAIN 拆分访问范围和剩余过滤

先看计划中的事实，再讨论“用了几列”。key 是实际选择的索引，key_len 是优化器决定使用的键长度线索；对可空列、字符集和数据类型，它不是简单的列数计数。rows 是估算要检查的行数，filtered 是估算过滤比例，Extra 则补充覆盖读取或附加过滤等信息。

-- 只查看计划，不执行查询；实际 rows 与 filtered 取决于统计信息
EXPLAIN FORMAT=TRADITIONAL
SELECT id, status, created_at
FROM orders
WHERE tenant_id = 7
  AND created_at >= '2026-01-01'
  AND status = 'paid';

反例：把 status 提前不等于所有查询都更快

如果业务中经常同时固定租户和状态，再按时间拉取订单，可以评估另一种顺序：

-- 把两个高频等值条件放在范围列前，服务另一类查询形状
CREATE INDEX idx_orders_tenant_status_time
ON orders (tenant_id, status, created_at);

这会让 (tenant_id, status) 先形成更窄前缀，再对 created_at 做范围扫描。但如果另一条高频查询只按租户和时间查、几乎不带状态，原顺序可能更合适。索引排序是工作负载取舍：要看查询组合、选择性、排序需求、回表列和写入维护成本，而不是套用“等值在前、范围在后”后就结束。

改索引前的判断清单

• 确认范围列前是否已经有稳定的等值条件，且列顺序与主要查询一致。
• 对比 key_len 与预期键部分，结合 rows 和 filtered 判断是否扫描过宽。
• 检查后列是否只是过滤、是否能通过覆盖读取减少回表，避免把“能读到”误判为“能缩小范围”。
• 用代表性数据和多条核心 SQL 对比计划；新增索引会增加磁盘占用以及写入、更新、删除成本。

相关问题

范围条件一定要放在联合索引最后吗？

不一定。应先满足主要查询的前缀和排序需求；“范围列靠后”只是常见取舍，不是脱离工作负载的硬规则。

key_len 变长就代表查询一定更快吗？

不代表。它只是使用键长度的线索，还要结合 rows、filtered、回表情况和实际耗时判断。

后列条件写在 WHERE 里还有意义吗？

有意义。它仍然负责正确过滤结果，并可能参与索引条件下推或覆盖读取；只是不能默认它继续缩短同一个连续 range。