bitmap join 通过位图标记逻辑删除而非物理删除，利用位运算高效过滤；但位运算（如&、|）在join中无法触发索引，需改用常量维度表或关联表实现等值连接以保障性能。
Bit位JOIN不能直接走索引，必须用常量表+位运算重写逻辑，否则性能会断崖式下跌。
为什么 WHERE flags & 4 无法用于 JOIN 条件
数据库优化器不把位运算（如 &、|、^）识别为可下推的等值条件，所以 ON u.flags & b.mask = b.mask 这类写法：
- 不会触发索引查找，哪怕 flags 字段有 B-Tree 索引
- 执行计划里 type 往往是 ALL 或 index，key 为 NULL
- 实际变成对左表每行都扫描右表所有位掩码组合，复杂度爆炸
用常量表 + 显式枚举替代位运算 JOIN
把位掩码含义固化成一张小而稳定的维度表（比如 permission_bits），再用标准等值 JOIN 替代位运算逻辑：
CREATE TABLE permission_bits ( id TINYINT PRIMARY KEY, name VARCHAR(32) NOT NULL, mask INT UNSIGNED NOT NULL, UNIQUE KEY uk_mask (mask) );
填充常见权限位：
INSERT INTO permission_bits VALUES (1, 'read', 1), (2, 'write', 2), (3, 'delete', 4), (4, 'admin', 8);
然后改写原查询：
❌ 原低效写法（无法走索引）：
SELECT u.name FROM users u WHERE u.flags & 4;
✅ 优化后（可走 uk_mask 索引）：
SELECT u.name FROM users u INNER JOIN permission_bits p ON u.flags & p.mask = p.mask WHERE p.mask = 4;
但注意：上面这句仍含位运算，只是缩小了右表范围；真正推荐的是反向建模——把用户-权限关系拆成关联表：
- 新增
user_permissions(user_id, bit_id)，主键或唯一索引为(user_id, bit_id) - 插入时按位展开：flag=6（即
read|write）→ 插入两行：(1001, 1)和(1001, 2) - 查询“有 delete 权限的用户”就变成干净的等值 JOIN：
SELECT u.* FROM users u JOIN user_permissions up ON u.id = up.user_id WHERE up.bit_id = 3
BIT_COUNT() 和 POW(2, n) 在 JOIN 中的陷阱
这些函数在 ON 或 WHERE 中出现时，同样会导致索引失效：
-
ON u.flags = POW(2, b.pos)→POW是计算型表达式，无法利用flags索引 -
WHERE BIT_COUNT(u.flags) > 2→ 全表计算位数，无索引可用 - 即使你给
flags加函数索引（MySQL 8.0+），BIT_COUNT(flags)也无法被JOIN条件复用
真正可行的路径只有一条：把位的语义提前物化，用整数 ID 或字符串标识代替运行时计算。
什么时候必须保留位存储？那至少加生成列索引
如果业务强依赖单字段存多位（如 IoT 设备状态字、协议标志位），且无法改表结构，可退一步用生成列 + 函数索引兜底：
ALTER TABLE users ADD COLUMN has_delete TINYINT GENERATED ALWAYS AS ((flags & 4) = 4) STORED, ADD INDEX idx_has_delete (has_delete);
之后就能写：
SELECT u.* FROM users u WHERE u.has_delete = 1;
但注意：
- 该索引仅对固定掩码（如 & 4）有效，换一个值就得新加一列
- STORED 列占额外磁盘空间，高频更新字段慎用
- 无法用于多掩码 OR 查询（如 has_read OR has_write），仍需回表或全扫
位运算 JOIN 的本质矛盾在于：数据库索引是为等值/范围设计的，不是为位模式匹配设计的。想让它快，就得放弃“一行存多位”的表意便利，把位含义提前落地为可索引的实体。
