位运算查询高效的关键在于字段必须用无符号整型（如tinyint unsigned）、加not null约束、where条件加括号确保优先级、增删状态用原子sql（如|、& ~），且&查询天然难走索引，仅精确匹配或生成列索引才有效。
字段类型必须用无符号整型，别碰 SIGNED 或 VARCHAR
位运算只认二进制位，一旦字段类型出错，隐式转换会让 & 结果不可靠。比如用 INT SIGNED 存权限，-1 的二进制补码会干扰判断；用 VARCHAR 存数字字符串，status & 1 直接返回 0（字符串转整数失败）。
实际选型看状态数量：
• ≤8 种：用 TINYINT UNSIGNED（0–255），省空间也够用
• 9–16 种：选 SMALLINT UNSIGNED
• 超过 16 种但不到 32 种：用 INT UNSIGNED，别用带符号的
• 字段必须加 NOT NULL 约束——NULL & 1 结果是 NULL，WHERE 条件直接失效，查不到数据还不报错
查询时括号不能省，& 和 | 的优先级坑过很多人
写 WHERE status & @MON | @WED 看似想查“周一或周三”，实际执行顺序是先 status & @MON，再 | @WED，结果恒为真（只要 @WED ≠ 0）。正确写法必须加括号：
• 查“含周一或周三任意一个”：WHERE (status & (@MON | @WED)) != 0
• 查“同时含周一和周三”：WHERE (status & (@MON | @WED)) = (@MON | @WED)
• 掩码建议在存储过程开头统一定义：SET @MON = 1, @TUE = 2, @WED = 4;，别硬写 1、2、4，否则哪天顺序一乱全错
增删状态必须原子更新，禁止读-改-写
应用层先 SELECT status，再算新值，最后 UPDATE，并发时必然丢状态。MySQL 本身支持单条语句完成：
• 开启某状态（如绑定微信，掩码=4）：UPDATE users SET status = status | 4 WHERE id = ?
• 关闭某状态（如取消 VIP，掩码=8）：UPDATE users SET status = status & ~8 WHERE id = ?（注意是 ~8，不是 -8）
• 切换状态（有则关、无则开）：UPDATE users SET status = status ^ 1 WHERE id = ?
所有操作都依赖 MySQL 行锁保证原子性，不用额外加事务
索引不是万能的，& 查询天然难走索引
WHERE status & 7 != 0 这类条件，MySQL 无法用 B+ 树索引做范围跳转，只能快速过滤掉 status = 0 的行，其余仍需逐行计算。真正能走索引的只有：
• 精确匹配：WHERE status = 5
• 前缀范围（极少见）：WHERE status BETWEEN 1 AND 15
如果高频查“同时具备 A 和 B”，不如冗余一个生成列：ADD COLUMN has_ab TINYINT GENERATED ALWAYS AS ((status & 3) = 3) STORED，再对它建索引。别幻想给 status & 3 建函数索引——MySQL 不支持这种非确定性表达式索引
NOT NULL，线上出问题时最难排查。
