MySQL本身不支持原生位图索引，但可通过ENUM/SET类型、位运算组合索引、物化视图+外部位图库（如Redis Bitmaps）或辅助表模拟实现，适用于性别、状态等低基数列的高效多条件过滤。
为什么不能直接 CREATE BITMAP INDEX
你执行 CREATE BITMAP INDEX idx ON t(col) 会报错 ERROR 1064 —— MySQL 所有官方存储引擎（InnoDB、MyISAM、Memory）均未实现该语法。所谓“位图索引”在 MySQL 中是概念性借鉴，不是可创建的对象。部分旧资料提到 USING bitmap 或 ENGINE=MEMORY + 特殊语法，实为误传或混淆了 Percona XtraDB、MariaDB 或 Oracle MySQL 分支的扩展功能。
用 ENUM 或 TINYINT 替代字符串，让优化器更好走索引
低基数字段若用 VARCHAR(20) 存 'active'/'inactive'，不仅浪费空间，还可能因隐式类型转换或排序规则导致索引失效。
-
ENUM('active','inactive','pending')：物理存储为 1 字节整数（最多 255 值），且值有序，WHERE status = 'active'能命中 B-Tree 索引 -
TINYINT UNSIGNED配常量映射（如 1→active, 2→inactive）：更轻量、无字符集开销，且支持范围查询（如status IN (1,2)） - 避免用
SET存多状态（如SET('read','write','delete')）来“假装位图”——它底层是位掩码，但WHERE perms & 1无法使用索引，全表扫描风险高
对多状态组合查询，用预计算位图列 + BIT 运算代替多次 OR/AND
当你要高频执行类似 WHERE gender = 'male' AND status = 'active' AND level IN ('vip','premium') 这类多等值条件时，B-Tree 索引只能用上一个（最左前缀），其余靠过滤。此时可主动建一列存“逻辑位图”：
假设你有 3 个低基数字段：gender（2 值）、status（3 值）、level（4 值），总组合 ≤ 24 种。你可以：
- 定义映射：gender→bit0~1（0=male,1=female），status→bit2~3（0=inactive,1=active,2=pending），level→bit4~5（0=normal,…）
- 加一列
bitmap TINYINT UNSIGNED，用触发器或应用层写入时计算：INSERT ... VALUES (..., (gender_val) | (status_val - 查询“male + active”就变成：
WHERE bitmap & 5 = 5（因为 male=0, active=1 → 0 | (1bitmap = 4 精确匹配） - 注意：
bitmap & N无法走索引，必须用=或IN才行；若真要模糊匹配（如“所有 male 用户”），仍得回退到原字段索引
真正省事又有效的做法：给每个低基数字段单独建 B-Tree 索引
别被“位图”二字带偏。InnoDB 对低基数列的单列索引效率极高——叶子节点少、缓存友好、范围小。只要满足：
- 该列
SELECT COUNT(DISTINCT col)/COUNT(*)95%） - 查询以
=、IN、IS NULL为主，基本不用>、BETWEEN - 写入不频繁（每秒更新
那么 CREATE INDEX idx_status ON users(status) 就是最简单、最稳定、最兼容的方案。EXPLAIN 显示 type: ref 或 type: const 即表示生效；配合 SELECT ... WHERE status = 'active' ORDER BY created_at LIMIT 20，还能顺便覆盖排序需求。
VARCHAR 改成 ENUM、加上单列索引、再用 pt-query-digest 看看慢查里它到底参没参与过滤——真实世界里，90% 的状态字段优化止步于此就已足够。 
