MySQL不支持Bitmap查询，BIT_COUNT()、CONV()和SET类型仅用于数值或字符串操作，无法实现位图索引功能，硬套位运算会导致逻辑错误或性能问题。
MySQL 本身不支持 Bitmap 查询，别在 WHERE 里硬套 bitset 函数
MySQL 没有内置的位图（Bitmap）数据结构用于存在性判断，BIT_COUNT()、CONV() 或 SET 类型都只是数值/字符串操作工具，不能替代位图索引。试图用 WHERE (bitmap_col & (1 做“位图查询”，本质是全表扫描 + 位运算，性能比普通索引还差。真正能起作用的位图思想，只存在于两个地方：应用层预过滤（如布隆过滤器）、或列存分析引擎的二级索引（如 <code>BLOOM_FILTER 索引）。
用 Redis + Bloom Filter 在查询入口拦截无效 ID
这是目前最主流、最可控的方案。核心不是让 MySQL 做位图，而是让它少被查——把“ID 一定不存在”的请求拦在数据库之前。
-
bloomFilter.mightContain(id)必须是请求处理的第一步，不是缓存没命中之后才调；顺序错就等于没加 - ID 类型必须严格对齐：如果数据库里是
VARCHAR，布隆过滤器里就得加"12345"，不是12345（Long）或"user:12345"（除非缓存 key 也这么设计） - 预热要全量：从
SELECT id FROM users WHERE status = 1拉出所有有效 ID，统一格式后批量add进去 - 增量写入时，每次
INSERT成功后必须同步bloomFilter.add(new_id)；删数据无法同步删除，只能接受短期误判或定期重建
列存分析引擎中启用 BLOOM_FILTER 索引（仅限特定场景）
如果你用的是支持列存二级索引的分析型 MySQL 兼容引擎（如某些 OLAP 分支），且字段满足条件，可以直接建 BLOOM_FILTER 索引加速等值查询：
- 只对
=和IN有效，!=、>、函数包裹列全部失效 - 字段类型受限：最大长度 256 的
STRING、INT、DATE等，不支持表达式或联合列 - 建索引语句示例：
CREATE INDEX idx_bf_sku ON orders (sku) USING BLOOM_FILTER - 生效前提是查询走的是该引擎的列存路径，普通 InnoDB 表完全不识别这个语法
低基数字段别强求位图，优先用 B+ 树单列索引
很多人想用位图优化 status、is_deleted 这类字段，其实没必要。InnoDB 对低基数列的 B+ 树索引非常高效：
- 叶子节点少（常为 1～2 层），缓存友好，随机点查快
- 配合
IN写法比=更稳，尤其统计信息陈旧时：WHERE status IN ('active') - 避免隐式转换：字段是
ENUM('active','inactive')，就写status = 'active'，别写status = 1 - 真要极致优化多条件组合（如
gender='M' AND level='vip'），用 MySQL 8.0+ 的生成列 + 函数索引，比手动维护位图安全得多
expectedInsertions 设太小），实际误判会远超预期，导致数据库压力不降反升。 
