给 status 加索引反而更慢：低基数字段的选择性分析与联合索引取舍

一、现象与背景：加了索引，P99 反而涨了 30%

上个月给一套订单系统做慢查询治理。核心表 t_order 规模：1200 万行、单表 3.1GB、InnoDB、MySQL 8.0.32。业务方甩来一条高频查询：

SELECT id, order_no, amount, create_time
FROM t_order
WHERE status = 1
  AND create_time > '2024-01-01'
ORDER BY create_time DESC
LIMIT 20;

status 是订单状态，取值只有 5 个枚举：0 待支付 / 1 已支付 / 2 已发货 / 3 已完成 / 4 已取消。

按最直觉的做法，DBA 给 status 单列加了个二级索引 idx_status。结果压测下来：该接口 P99 从 1.8s 涨到 2.4s，慢了 30%。加索引非但没救，反而更糟。业务方当场质疑「你们是不是乱改」。

二、根因分析：选择性太低，回表放大吞掉了索引收益

问题出在**选择性（selectivity）**上。

• status 只有 5 个取值，单个值的频率约 20%（status=1 的已支付订单约 240 万行）。
• 二级索引只存 status + 主键 id。命中 status=1 后，InnoDB 要拿 240 万个主键回表去聚簇索引取 order_no / amount / create_time。
• 而 create_time > '2024-01-01' 这个条件索引里根本没有，只能在回表后逐行过滤——先取 240 万行、再过滤、再排序、再取 20 行。

反观不加索引走全表扫描：顺序扫 1200 万行的聚簇索引，边扫边过滤，虽然扫得多，但没有 240 万次随机回表 + 排序的额外开销。

优化器的成本模型在这里「看走眼」的诱因是：EXPLAIN 里 type 从 ALL 变成了 ref，看着像升级了，可 rows 估算仍是 240 万，Extra 里带着 Using where; Using filesort。ref 只是访问类型好看，不等于总成本低。

一句话：当单个索引值对应的行数（240 万）已经接近表总量（1200 万）的一半时，回表 + 排序的成本会反超全表扫描。这就是「低基数索引负收益」的本质。

三、具体做法：用基数说话，再上联合索引

1. 先量化选择性，别拍脑袋

-- information_schema 里的基数（估算值，注意是采样）
SELECT index_name, column_name, cardinality
FROM information_schema.statistics
WHERE table_schema = 'order_db' AND table_name = 't_order';

-- 真实基数（这才是选择性计算的依据）
SELECT status, COUNT(*) AS cnt
FROM t_order
GROUP BY status;

status=1 实测 240.6 万行，选择性 240.6 / 1200 ≈ 0.20。经验阈值：单列选择性高于 0.2（即一个值对应超过 20% 的行）时，单列索引往往不划算，要联合别的列。

2. 把高选择性列前置，构成联合索引

create_time 是连续时间戳，选择性极高。建联合索引（等值列在前、范围列在后）：

ALTER TABLE t_order
  ADD INDEX idx_status_create_time (status, create_time);

status 等值命中后，索引内 create_time 已有序，> '2024-01-01' 直接范围扫描，ORDER BY create_time DESC 也顺势免掉 filesort。

3. 用 FORCE INDEX 做 A/B 实测，别信单一 EXPLAIN

-- 走新联合索引
SELECT /*+ INDEX(t_order idx_status_create_time) */
  id, order_no, amount, create_time
FROM t_order
WHERE status = 1 AND create_time > '2024-01-01'
ORDER BY create_time DESC
LIMIT 20;

实测对比（同一压测脚本，QPS 恒定）：

| 方案 | P99 | 备注 | |------|-----|------| | 无索引（全表扫） | 1.8s | filesort | | 单列 idx_status | 2.4s | 240 万行回表 + filesort，更慢 | | 联合 idx_status_create_time | 38ms | 免 filesort，范围命中 |

联合索引把 P99 从 1.8s 打到 38ms，比不加索引还快 40 多倍。单列索引那个 ref 纯属「好看」，删掉它对系统只有好处。

四、踩过的坑 / 反直觉之处

1. type 变 ref 不等于变快。 很多团队（包括当时的值班同学）一看访问类型从 ALL→ref 就验收了，真正拖慢的是 rows 和 Extra 里的 filesort。看 EXPLAIN 要盯 rows、filtered、Extra 三个，别只看 type。
2. information_schema 的 cardinality 是估算。 我见过它显示 idx_status 基数 5，但真实分布严重倾斜——status=1 占 41%（240 万），status=0 只占 3%。用「平均值」判断选择性会严重误判，必须 GROUP BY 拿真实分布。
3. 索引不是越多越好。 每多一个二级索引，每次 INSERT/UPDATE 都要多维护一棵 B+ 树。订单表每秒几千次写入，那个无用的 idx_status 是持续的写放大成本，纯亏。
4. 删索引要灰度。 DROP INDEX 在大表上同样要评估 Online DDL 窗口，别在生产高峰期裸删。

五、结论与可复用清单

结论： 给低基数字段单列加索引，在「单值占比 > 20%」时大概率是负收益——回表放大 + filesort 会反超全表扫描。正确路径是先用真实基数判断选择性，再把高选择性列组合成联合索引。

可复用清单（慢查询治理前自查）：

1. 拿到慢 SQL，先 GROUP BY 出 WHERE 列的真实基数分布，别信 information_schema 的估算值。
2. 算选择性：单值行数 / 总行数。> 0.2 的单列，优先考虑联合索引或改写查询，而不是单列加索引。
3. 联合索引按「等值列在前、范围列在后、排序列尽量收进索引」排列，目标是干掉 Using filesort。
4. 验收看 rows / filtered / Extra，用 FORCE INDEX 做 A/B 实测，而不是只看 type。
5. 加索引前问一句：这张表写入频繁吗？这个索引每次写都要多维护一棵 B+ 树，值不值？
6. 确认无用索引后，在低峰窗口灰度 DROP INDEX，别裸删。

一句话收尾：索引是拿写放大换读加速的交易，选择性是这笔交易的定价依据；低基数单列，往往是笔亏本买卖。