mysql位运算存状态应避免bit类型，因其非数值、需显式转换且orm兼容差；推荐用tinyint/smallint/int unsigned，配合括号确保&优先级，用|开启、&~关闭、^切换状态，但索引对位查询无效，大表需谨慎。
MySQL里用位运算存状态，别用 BIT 类型——它不实用，反而容易踩坑。直接用 TINYINT、SMALLINT 或 INT 就行，语义清晰、兼容性好、查询写法统一。
为什么避开 BIT 类型
BIT 在 MySQL 中本质是二进制字符串，不是数值类型。你不能对它直接做 &、| 运算，必须先 CONVERT(... AS UNSIGNED) 或隐式转成整数，否则会报错或行为异常。比如 SELECT status & 1 FROM t WHERE status IS BIT(8) 可能返回空结果或警告，因为 MySQL 会把 BIT 当作带前导零的二进制字面量处理，而非可计算的整数。
更麻烦的是：ORM（如 MyBatis、SQLAlchemy）和客户端驱动对 BIT 的映射不一致，PHP 的 mysqli 默认返回 NULL，Go 的 database/sql 可能返回 []byte，需要额外转换逻辑。
所以实际项目中，99% 的位状态存储都用 TINYINT UNSIGNED（0–255，8 位）、SMALLINT UNSIGNED（0–65535，16 位）或 INT UNSIGNED（0–4294967295，32 位）。
& 查询必须加括号，否则逻辑全错
MySQL 中 & 的优先级低于 =、!=、> 等比较操作符。不加括号会导致表达式被错误解析。
- ❌ 错误写法：
WHERE roles & 3 = 3→ 实际等价于WHERE roles & (3 = 3)→WHERE roles & 1，永远只检测 bit 0 - ✅ 正确写法：
WHERE (roles & 3) = 3→ 检测 bit 0 和 bit 1 是否同时为 1 - ✅ 查“有任意一个权限”：
WHERE (roles & 7) != 0（7 = 111b，覆盖前三位） - ✅ 查“没有禁用状态（bit 4）”：
WHERE (roles & 16) = 0
更新状态：用 | 开启、& ~ 关闭、^ 切换
所有操作都基于幂次掩码（1, 2, 4, 8, 16…），不要用加减法——加减在有进位时会破坏其他位。
- 开启 VIP（bit 3，值为 8）：
UPDATE users SET status = status | 8 WHERE id = 123 - 关闭手机验证（bit 1，值为 2）：
UPDATE users SET status = status & ~2 WHERE id = 123（~2是按位取反，结果为全 1 除 bit 1 为 0） - 切换邮箱验证状态（bit 0）：
UPDATE users SET status = status ^ 1 WHERE id = 123 - ⚠️ 避免：
status = status + 8或status = status - 2—— 若原值是 255（11111111），+8 会溢出变 0，清空所有状态
索引对位查询无效，大表务必谨慎
MySQL 无法为 (status & 8) = 8 这类表达式使用索引。即使你在 status 字段建了 B+Tree 索引，执行计划里仍显示 type: ALL（全表扫描）。
这意味着：如果表有百万级数据，又频繁执行 WHERE (status & X) = X，性能会急剧下降。
可行的缓解方式只有两个：
- 把高频查询的状态单独拆成布尔字段（如
is_vip TINYINT(1) DEFAULT 0），并为其建索引 - 用生成列（Generated Column）+ 函数索引（MySQL 5.7+）：
ALTER TABLE users ADD is_vip TINYINT AS ((status & 8) = 8) STORED，再CREATE INDEX idx_is_vip ON users(is_vip)
位运算省字段的代价是牺牲查询性能——这点在设计初期就得想清楚，别等到上线后才发现慢得没法接受。
