联合索引列顺序怎么定：从等值、范围到排序逐项判断

联合索引列顺序最容易被一句“区分度高的列放前面”带偏。真正应该先看的不是字段统计，而是查询形状：哪些条件是等值，哪个条件第一次变成范围，排序列是否紧接在可用前缀之后，以及这条索引还要服务哪些查询。

实用判断顺序是：先组织连续的等值前缀，再确定首个范围列，最后判断排序列和方向能否沿同一棵 B-tree 连续读取。区分度是成本因素，不是脱离查询形状的唯一规则。

问题：为什么只按区分度排序经常失效

假设订单表主要按租户、状态和创建时间查询。下面这条查询要求返回某个租户的已完成订单，限定最近时间，并按时间倒序稳定翻页：

SELECT id, customer_id, amount, created_at
FROM orders
WHERE tenant_id = 42      -- 等值条件：固定租户
  AND status = 2          -- 等值条件：固定订单状态
  AND created_at >= '2026-10-01 00:00:00' -- 范围条件：限定时间下界
ORDER BY created_at DESC, id DESC -- id 作为相同时间下的稳定排序键
LIMIT 50;                 -- 控制单次返回量

如果只看单列区分度，created_at 或 id 可能比 status 更“唯一”，但把范围列提前会改变可构造的索引区间。MySQL 对多列 B-tree 索引按最左前缀使用；在范围优化中，连续的 =、 或 IS NULL 可以继续扩展区间，一旦遇到 >、、>=、、BETWEEN 等范围比较，后续列通常不再参与缩小该区间。

最小配方：等值列在前，范围列随后

针对上面的主查询，一个直接候选是 (tenant_id, status, created_at, id)。前两列形成连续等值前缀，created_at 形成第一个范围，id 主要承担稳定排序和游标边界。表结构可以这样准备：

CREATE TABLE orders (
    id BIGINT UNSIGNED NOT NULL,             -- 全局订单主键
    tenant_id BIGINT UNSIGNED NOT NULL,      -- 租户隔离字段
    status TINYINT UNSIGNED NOT NULL,         -- 订单状态
    created_at DATETIME(6) NOT NULL,          -- 创建时间，保留微秒
    customer_id BIGINT UNSIGNED NOT NULL,     -- 客户编号
    amount DECIMAL(12, 2) NOT NULL,           -- 订单金额
    PRIMARY KEY (id),                         -- InnoDB 聚簇主键
    KEY idx_tenant_status_created_id (
        tenant_id,                            -- 先固定租户
        status,                               -- 再固定状态
        created_at DESC,                      -- 接着限定时间并支持倒序
        id DESC                               -- 最后提供稳定次序
    )
) ENGINE = InnoDB;                            -- 使用 InnoDB 存储引擎

这里的“后续列不再缩小区间”不是“后续列完全没用”。根据实际执行计划，后续列仍可能用于索引条件下推、排序、覆盖读取或减少回表后的过滤成本。设计时要把“构造扫描边界”和“扫描过程中继续利用索引信息”分开理解。

等值列之间，谁放在最前面

当 tenant_id 与 status 都是等值条件时，两者都能组成连续前缀，不能简单地说选择性更高者永远在前。更实际的判断是看左侧前缀能否被其他高频查询复用：

在多租户业务中，tenant_id 通常是更稳定的首列，因为它限定数据边界，也便于服务“某租户的全部订单”。但这仍是工作负载结论，不是语法定律。

排序配方：固定前缀后检查列与方向

MySQL 可以利用索引顺序完成 ORDER BY，即使排序表达式没有写出索引的全部前导列，只要缺少的前导列在 WHERE 中被常量固定。这里 tenant_id 和 status 都是常量，后续的 created_at DESC, id DESC 与候选索引一致，因此具备使用索引顺序的条件。

如果所有排序列方向整体反转，例如从两个 DESC 变成两个 ASC，优化器可以考虑反向扫描同一索引。若方向混合，例如 created_at DESC, id ASC，索引本身的升降序组合就要与查询匹配；否则执行计划可能出现 Using filesort。是否最终选择索引排序还受数据分布、范围大小、回表成本和 LIMIT 影响，因此不要把“具备条件”写成“必然采用”。

关键 SQL：用 EXPLAIN 验证，而不是凭感觉确认

先使用普通 EXPLAIN 观察计划，再在安全测试环境使用 EXPLAIN ANALYZE 获取实际执行信息。后者会真正执行查询，不应直接对高成本写法或生产流量随意运行。

EXPLAIN
SELECT id, customer_id, amount, created_at
FROM orders
WHERE tenant_id = 42      -- 固定联合索引第 1 列
  AND status = 2          -- 固定联合索引第 2 列
  AND created_at >= '2026-10-01 00:00:00' -- 第一个范围条件
ORDER BY created_at DESC, id DESC -- 检查是否需要额外排序
LIMIT 50;                 -- 与真实查询保持一致

重点看这些字段：

• key：最终选择了哪条索引；候选索引存在不代表优化器一定采用。
• key_len：计划最多使用到的索引前缀长度，可辅助判断等值前缀和范围列是否进入访问路径，但它不是“用了几列”的绝对口径。
• rows 与 filtered：估算扫描量和过滤比例；统计信息过旧时估算可能偏差。
• Extra：关注 Using filesort、Using index condition 与 Using index，它们分别描述排序、索引条件下推和覆盖读取等信息。

如果优化器选择了别的计划，先更新统计、检查条件类型和排序方向，再比较候选索引。不要仅靠 FORCE INDEX 把某次测试结果固定下来；数据规模变化后，强制计划可能比成本模型更差。

变体一：IN 看起来像等值，排序却可能变复杂

status IN (1, 2) 可以形成多个等值范围，但它不等于“单个常量固定前缀”。当每个状态对应一段按时间排序的数据时，把多段结果合并成全局的 created_at DESC 可能仍需额外排序。遇到 IN、多个范围或动态条件时，要用实际 SQL 查看 Extra，不要套用单值等式的结论。

EXPLAIN
SELECT id, created_at
FROM orders
WHERE tenant_id = 42      -- 第 1 列仍是单个常量
  AND status IN (1, 2)    -- 多个值会形成多个候选范围
  AND created_at >= '2026-10-01 00:00:00' -- 每段内部限定时间
ORDER BY created_at DESC, id DESC -- 检查多段合并是否需要 filesort
LIMIT 50;                 -- 保留真实分页条件

变体二：游标分页要把 id 放进比较条件

仅按时间排序时，同一微秒可能出现多条记录，翻页边界会不稳定。把 id 作为第二排序键，并让下一页条件与排序构成一致的元组，可以避免重复或遗漏：

SELECT id, customer_id, amount, created_at
FROM orders
WHERE tenant_id = 42      -- 固定租户
  AND status = 2          -- 固定状态
  AND created_at >= '2026-10-01 00:00:00' -- 业务时间窗口
  AND (created_at, id) 

这里同时出现时间下界和游标上界，实际区间如何构造仍由优化器决定。应使用接近生产分布的数据测量扫描行数和耗时，而不是根据 SQL 外观推断精确边界。

兼容坑：覆盖索引不是免费午餐

为了消除回表，有人会继续把 customer_id、amount 等返回列追加到索引尾部。这样可能让 Extra 出现 Using index，但也会增加索引页体积、缓存压力、写放大和维护成本。InnoDB 二级索引还会携带主键值，因此主键很宽时成本更明显。

是否扩成覆盖索引，至少要比较三件事：查询频率是否足够高、每次回表行数是否足够多、写入和更新是否能承受更宽的索引。如果 LIMIT 很小且数据页命中率高，增加两个业务列未必值得。

完整判断清单

1. 列出真实 WHERE、ORDER BY、LIMIT 和返回列，不先讨论索引。
2. 把单值等式组织成连续前缀，并根据其他查询的左前缀复用决定等值列内部顺序。
3. 找到第一个范围条件；它之后的列通常不再缩小扫描区间。
4. 固定前缀后，检查排序列的顺序、方向和稳定次键是否与索引连续匹配。
5. 用 EXPLAIN 看 key、key_len、rows、filtered 与 Extra。
6. 在安全环境用 EXPLAIN ANALYZE 比较实际行数、循环次数和耗时。
7. 最后才评估覆盖列，并把写入、存储和缓存成本一并纳入。

归纳起来，联合索引的核心不是找一条“万能列顺序”，而是让最常见查询在同一条有序路径上尽可能早地缩小范围、尽可能少地额外排序。查询形状变了，最合适的列顺序也可能随之改变。

官方参考

• MySQL 8.4：Range Optimization
• MySQL 8.4：How MySQL Uses Indexes
• MySQL 8.4：Optimization and Indexes
• MySQL 8.4：ORDER BY Optimization