MySQL原生不支持位图索引，对低基数字段应优先建单列B+树索引或合理组合索引；强行模拟位图索引易引发全表扫描、并发锁争用与事务不一致等问题，而优化查询写法、更新统计信息和使用生成列函数索引才是更安全高效的方案。
MySQL 原生不支持位图索引，强行模拟反而容易踩坑——直接建单列 B+ 树索引 + 合理写法，对低基数字段（如 status、is_deleted）通常就是最优解。
为什么别自己实现位图索引表
网上常见用 Gender_Bitmap 表存 0b101 这类二进制值，本质是手动维护位图。问题在于：
- 每次
INSERT/UPDATE都要同步更新位图表，应用层逻辑复杂且易出错 -
WHERE bitmap & 5 = 5这种写法无法使用任何索引，必然全表扫描 - InnoDB 的 MVCC 和行锁机制与位图的块级更新天然冲突，高并发下极易锁等待
- 位图表本身需要额外 JOIN 或子查询，执行计划常退化为嵌套循环
真正有效的低基数字段优化方式
不是“怎么造位图”，而是“怎么让现有索引被用上”：
- 给每个低基数字段单独建
B+ 树索引：InnoDB 对低基数列的单列索引非常友好——叶子节点少、缓存命中率高、范围小。例如INDEX(status)在只有 3 个值时，B+ 树深度常为 1～2 层 - 复合索引中把低基数字段放最左，但必须后接高基数列：比如
INDEX(is_deleted, created_at)，这样WHERE is_deleted = 0 AND created_at > '2026-01-01'才能走索引范围扫描 - 避免隐式类型转换：
status = 1（字段是ENUM或VARCHAR）会失效；统一用字符串字面量，如status = 'active' - 用
IN替代=有时更稳：优化器对status IN ('active')的选择率估算更准，尤其在统计信息陈旧时
当多条件等值过滤频繁时，优先考虑生成列 + 函数索引
比如你总查 WHERE gender = 'M' AND level = 'vip' AND region = 'CN'，且这三个字段都是低基数：
- MySQL 8.0+ 可建生成列：
ALTER TABLE users ADD COLUMN combo_key TINYINT AS (CASE WHEN gender='M' AND level='vip' AND region='CN' THEN 1 ELSE 0 END) STORED; - 再对其建函数索引：
CREATE INDEX idx_combo ON users(combo_key); - 查询直接写
WHERE combo_key = 1，走索引且无计算开销 - 比手动拼
bitmap列安全得多——不依赖触发器、不引入额外表、不破坏事务原子性
分区表仅在特定场景下有用
只有当你有明确的、长期稳定的、极低基数（通常 ≤ 3）且查询高度倾斜的字段时才考虑：
- 例如
is_deleted TINYINT，95% 数据是0，只偶尔查1，且业务接受物理隔离 - 用 LIST 分区：
PARTITION BY LIST (is_deleted) (PARTITION p0 VALUES IN (0), PARTITION p1 VALUES IN (1)) - 但注意：分区键必须是主键/唯一键的一部分，否则建表失败；且跨分区
ORDER BY或LIMIT性能可能下降
真正容易被忽略的是：低基数字段的索引是否被用上，往往取决于查询写法和统计信息新鲜度，而不是索引本身有多“高级”。先 ANALYZE TABLE，再 EXPLAIN 看 key 和 rows，比琢磨怎么造位图实在得多。
