mysql位运算适用于按位建模的状态字段，可高效开关/校验位，但需注意运算符优先级、索引失效及锁范围扩大等问题，正确用法包括|置1、&~置0、^翻转、(status&bit)!=0判断。
MySQL中用&、|、^直接操作状态位字段
状态字段若设计为整型（如 TINYINT 或 INT），且每个 bit 代表一个开关（例如：bit0=启用、bit1=锁定、bit2=已审核），就完全可以用位运算批量开关/校验，避免拆成多个布尔字段或 JSON 字符串。关键不是“能不能”，而是“字段是否真按位语义建模”——如果只是存个数字没约定 bit 含义，位运算是无意义的。
常见错误现象：UPDATE user SET status = status | 4 WHERE id IN (1,2,3) 执行后部分行没变，但其实是因为原 status 值本身已含 bit2（即值 ≥4），| 4 不会改变它；而误以为“没生效”就反复执行，导致逻辑冗余。
- 开启某位（置 1）：用
|，如status | 2（打开 bit1） - 关闭某位（置 0）：用
& ~，如status & ~8（关闭 bit3） - 翻转某位：用
^，如status ^ 1（切换 bit0） - 检查某位是否开启：WHERE 条件里用
status & 16 != 0，不能写成= 16（否则其他位同时为 1 就漏判）
WHERE 中用位判断必须加括号和非零比较
MySQL 对位运算符优先级处理较弱，status & 1 = 1 实际被解析为 (status & (1 = 1)) → status & 1，结果恒为真或假，不等于你想要的“bit0 是否为 1”。线上出过多次全表误更新事故。
正确写法只有两种：
-
WHERE (status & 1) != 0—— 明确、兼容所有 MySQL 版本 -
WHERE status & 1—— MySQL 允许非零即 true，但可读性差，不建议在复杂条件中混用
别用 = 1、> 0 或 IS TRUE，它们在不同版本或严格模式下行为不一致。
批量 UPDATE 多个位状态时，CASE 和位运算不是互斥的
纯位运算适合“统一开关”，但真实业务常需“按 ID 分别设置不同组合”，比如：ID=101 开启 bit0+bit2，ID=102 只关 bit1，ID=103 翻转 bit3。这时硬套 |/& ~ 写法会非常难维护。
推荐组合方案：
- 先用
CASE WHEN id = 101 THEN status | 5 WHEN id = 102 THEN status & ~2 ELSE status END—— 每个分支独立计算目标值 - 必须带
ELSE status，否则未匹配 ID 的行会被设为 NULL（尤其注意：NULL 与位运算结果不可逆） - WHERE 子句仍要预过滤，例如
WHERE id IN (101,102,103)，不能只靠 CASE 分支兜底
这种写法比拼接 N 条独立 UPDATE 更安全，也比应用层循环发包更省网络开销。
位运算 UPDATE 的隐性成本：索引失效与锁范围扩大
位运算本身不慢，但会让 WHERE 条件无法走索引。例如 WHERE (status & 4) != 0 是典型函数式条件，即使 status 有索引，MySQL 也无法使用。
实操建议：
- 高频查询 + 位字段更新场景，考虑冗余一个生成列（Generated Column），如
is_locked TINYINT AS ((status & 2) != 0) STORED，再给该列建索引 - 大表批量更新前，用
EXPLAIN确认实际扫描行数；若全表扫描，宁可加中间临时表预筛选 ID 列表 - 事务中执行位更新时，锁住的是满足 WHERE 条件的所有行——哪怕你只改其中几个 bit，锁范围仍由 WHERE 决定，不是由位操作粒度决定
位运算不是银弹，它把状态压缩进一个字段，也把调试难度和索引代价一并压缩进去了。上线前务必用真实数据量压测 WHERE 性能和锁等待时间。
