status字段单独建索引通常不高效，尤其当取值少、更新频繁时；真正有效的做法是把它作为联合索引的前导列，并配合高频查询条件使用。
直接说结论：status字段单独建索引通常不高效，尤其当取值少、更新频繁时；真正有效的做法是把它作为联合索引的前导列，并配合高频查询条件使用。
为什么CREATE INDEX idx_status ON orders(status)多数时候是低效的
status字段常见于订单、工单、用户等表，但它的值域往往极小（如 0/1/2/3 或 'pending'/'paid'/'shipped'/'cancelled'），导致选择性极低。MySQL优化器在评估时会发现：扫描索引再回表，可能比直接全表扫描还慢——尤其当表不大或该状态占比超20%时，EXPLAIN 中 type 很可能显示 ALL 或 index，而非预期的 ref。
- 区分度计算示例：
SELECT COUNT(DISTINCT status) * 1.0 / COUNT(*) FROM orders;若结果 - 写放大严重：每次
UPDATE ... SET status = 2 WHERE id = 123都要更新索引页，而 status 变更频率远高于其他字段 - InnoDB 的二级索引存储主键值，status 索引本身不减少回表次数，除非你只查
status列
用status做联合索引的左前缀，才真正起作用
绝大多数对 status 的查询都带时间、用户、类型等过滤条件。比如：SELECT * FROM orders WHERE status = 'shipped' AND created_at > '2026-05-01'。此时应建 INDEX idx_status_created ON orders(status, created_at)，而非单列索引。
- 必须把
status放在联合索引最左侧——否则WHERE created_at > ... AND status = ...无法命中索引 - 如果查询还常带
user_id，且user_id区分度远高于status，优先级应调整为(user_id, status, created_at)，但前提是WHERE条件中user_id是等值查询 - 避免冗余：已有
(status, created_at)，再建(status)单列索引毫无意义，InnoDB 可用前缀匹配
哪些场景下status索引反而有害
不是所有“加了索引就变快”，错误使用会让写入和空间成本陡增，而收益微乎其微。
- 表中
status值只有两种（如 soft-delete 的is_deleted），且其中一种占 95% 以上——优化器大概率弃用索引 - 业务逻辑频繁批量更新
status（如定时任务将 10 万条记录从pending改为processing），会引发大量索引页分裂与锁竞争 - 查询语句对
status使用函数或表达式：WHERE UPPER(status) = 'SHIPPED'或WHERE status IN (SELECT code FROM status_ref)，都会导致索引失效
验证是否真用上了索引，别只看“建了没”
建完索引必须用 EXPLAIN 实测真实查询，重点关注三个字段：
-
key：是否显示你刚建的索引名（如idx_status_created） -
rows：扫描行数是否显著下降（对比建索引前） -
Extra：是否出现Using index condition（ICP 下推）或Using index（覆盖索引）；若出现Using filesort或Using temporary，说明排序/分组仍没被索引优化
特别注意：测试时用真实数据量，空表或 100 行数据的结果不具备参考性。status 类字段的索引价值，往往在百万级以上数据 + 高频查询 + 合理联合条件下才真正显现。
