mysql 8.0 不支持位图索引，innodb 因 mvcc 和行级锁与位图整块更新冲突而无法实现；替代方案包括复合索引、生成列+部分索引、memory 表及查询结构优化。
MySQL其实没有原生位图索引
MySQL（包括 8.0 和最新 8.4）的 InnoDB 存储引擎不支持位图索引（Bitmap Index），CREATE INDEX ... USING BITMAP 会报错或被忽略。所谓“布尔值用位图索引优化”，是常见误解——实际执行中，MySQL 对 BOOLEAN（即 TINYINT(1)）字段仍使用 B+ 树索引，只是因值域极小（仅 0/1），B+ 树高度低、页内键值密集，查询效率看起来“像位图”。
为什么给 bool 字段建普通 B+ 树索引仍然有效？
虽然不是位图，但对高基数低分布字段（如 is_active 只有 0 和 1），B+ 树索引依然能显著减少 I/O：
- 树高通常为 2～3 层，即使千万级数据也只需 2～3 次磁盘随机读
- 每个索引页可容纳大量重复键值（比如 1000 个
is_active = 1记录共用一个叶子页） - 配合
WHERE is_active = 1这类等值查询，能快速定位到第一个匹配记录，再沿叶子链表顺序扫描 - 若查询带
LIMIT（如取前 10 个活跃用户），常能提前终止扫描
哪些操作会让 bool 索引失效？
看似简单的布尔查询，稍不注意就触发全表扫描：
-
WHERE is_active != 0或WHERE NOT is_active：部分旧版本 MySQL 无法利用索引做非等值否定扫描 -
WHERE is_active IS TRUE：语法合法但可能绕过索引（取决于 MySQL 版本和 SQL 模式） -
WHERE is_active + 0 = 1：表达式导致隐式类型转换，索引失效 - 在
OR条件中混用其他无索引字段，如WHERE is_active = 1 OR status = 'pending'，且status无索引时，整个条件可能放弃使用is_active索引
真正提升大批量布尔筛选性能的替代方案
当单靠索引仍不够快（例如需秒级返回百万级 is_deleted = 0 的记录），应考虑架构层优化：
- 将热冷数据物理分离：把
is_active = 0（已注销/软删除）的记录归档到另一张表，主表只保留活跃数据 - 用分区表按布尔字段分区（如
PARTITION BY LIST (is_active)），让优化器直接跳过整个分区 - 业务上改用「状态机 + 时间戳」替代纯布尔字段，例如用
status ENUM('active', 'inactive', 'archived')并对updated_at建联合索引，便于按时间范围快速切片 - 高频只读场景下，用物化视图（MySQL 8.4+ 支持
CREATE MATERIALIZED VIEW）或应用层缓存预聚合结果
别指望 MySQL 自动给你变出位图索引——它用的是 B+ 树，但只要写法干净、数据分布真实倾斜（比如 95% 是 0）、且查询模式稳定，这个“最朴素”的索引，就是你当前最可靠的选择。
