mysql不支持位图索引，对低基数字段如status建单列索引常被优化器跳过，因其选择率高导致回表开销大于全表扫描；有效替代方案包括复合索引（如idx_status_created）、生成列+函数索引、list分区及查询精简。
MySQL 不支持位图索引，对 status 这类低基数字段（比如只有 3–5 个取值）直接建 INDEX(status) 通常无效——优化器会跳过它，走全表扫描。这不是你建错了，是 B+ 树索引在这种场景下本就不该单独存在。
为什么 status = 'active' 走不了索引？
优化器估算出 status 的选择率太高（比如 30% 行都满足条件），认为走索引再回表比直接全表扫描还慢。哪怕你加了单列索引，EXPLAIN 里也常显示 type: ALL。
- 验证方式：运行
SELECT COUNT(DISTINCT status)/COUNT(*) FROM orders;，结果 > 0.1 就大概率被跳过 - 不是“没用”，而是“用了更慢”——B+ 树索引要按主键回表，大量随机 IO 拖垮性能
-
WHERE status IN ('active')有时比=更容易触发索引（优化器对 IN 的选择率估算更保守）
用复合索引把低基数字段“盘活”
单列索引失效，但把它放在复合索引最左列 + 后接高基数列，就能让范围扫描真正落地。
- 推荐写法：
ALTER TABLE orders ADD INDEX idx_status_created (status, created_at); - 适用查询：
WHERE status = 'shipped' AND created_at > '2026-01-01'—— 索引能用上两列 - 避免
SELECT *，只查id、user_id等必要字段，减少回表量 - 如果常查
status+user_id，且user_id基数高，就换成(status, user_id)
用生成列 + 函数索引做“软位图”
MySQL 8.0+ 支持生成列和对其建函数索引，可把多条件压缩成一个可索引的表达式。
- 例如高频查询：
WHERE status = 'completed' AND amount >= 100 - 添加生成列：
ALTER TABLE orders ADD COLUMN is_high_value_completed TINYINT GENERATED ALWAYS AS ((status = 'completed') AND (amount >= 100)) STORED; - 建索引：
CREATE INDEX idx_hvc ON orders (is_high_value_completed); - 查询时直接用：
WHERE is_high_value_completed = 1，索引百分百命中
分区表物理隔离重复值
对极低基数字段（如 is_deleted TINYINT 只有 0/1），LIST 分区能直接砍掉一半数据扫描量。
- 建表时分区：
CREATE TABLE orders (...) PARTITION BY LIST (is_deleted) (PARTITION p0 VALUES IN (0), PARTITION p1 VALUES IN (1)); - 查询
WHERE is_deleted = 0时，优化器只会读p0分区，I/O 直接减半 - 注意：分区字段必须是整型或枚举，不能是 VARCHAR；且需确保查询条件能精确匹配分区值
真正难的不是“怎么加索引”，而是判断哪些查询路径值得优化——比如统计类查询（COUNT(*) WHERE status = ...）更适合用物化视图或定时汇总表，而不是硬扛索引。位图索引的本质是空间换时间，而 MySQL 的替代方案，核心是用结构设计把“空间”提前收进来，把“时间”留在查询那一刻。
