单用户权限判定必须用&运算符写在WHERE子句中，BIT_AND/BIT_OR是聚合函数，仅限GROUP BY上下文使用；权限值须为2的幂，组合判断应构造复合掩码；大表需建生成列+索引优化性能；字段类型必须为整型，NULL需谨慎处理。
WHERE里用&判断权限，别碰BIT_AND/BIT_OR
单用户权限判定必须用&运算符写在WHERE子句里，BIT_AND和BIT_OR根本不能用在这里——它们是聚合函数，只在GROUP BY上下文中合法。写成WHERE BIT_OR(perm_mask) = 4会直接报错：Invalid use of group function。
常见错误现象：
- 把
BIT_OR当“查这个用户有没有权限”用，结果语法报错 - 误以为
(perm_mask & 4) > 0和(perm_mask & 4) = 4等价，忽略NULL字段导致整行不命中（前者对NULL返回NULL，条件不成立；后者同理，但语义更明确） - 漏括号，写成
perm_mask & 4 = 4，被解析为perm_mask & (4 = 4)→perm_mask & 1，逻辑全错
&掩码组合的三种典型写法
权限值必须是2的幂（1、2、4、8…），否则&无法准确分离单个位。组合判断不是拼AND，而是构造复合掩码再匹配：
- 查“有删除权限（bit 2，值为4）”：
WHERE (perm_mask & 4) = 4 - 查“同时有读（1）和写（2）”：
WHERE (perm_mask & 3) = 3（因为1 | 2 = 3） - 查“有读或删除（至少一个）”：
WHERE (perm_mask & 5) != 0（因为1 | 4 = 5）
注意：!= 0适用于“或”逻辑，但= mask才是“且”的可靠写法；用> 0在某些数据库隐式转换场景下可能触发警告。
大表查询性能差？加生成列+索引
WHERE (perm_mask & 4) = 4基本无法走索引——优化器没法把位运算反推成可索引条件。百万级以上表必须冗余布尔生成列：
- 添加生成列：
ALTER TABLE users ADD has_delete TINYINT AS ((perm_mask & 4) = 4) STORED - 对该列建索引：
CREATE INDEX idx_has_delete ON users(has_delete) - 查询时直接用：
WHERE has_delete = 1，就能走索引
字段类型必须是整型（TINYINT、INT等），VARCHAR或TEXT会静默转成0，所有权限校验失效。
聚合场景才轮到BIT_OR和BIT_AND
只有当你需要统计“某个角色组整体覆盖哪些权限”或“全员都开启的权限位”时，才用这两个函数，且必须配合GROUP BY：
-
BIT_OR：某组中至少一人有该权限 →SELECT role_id, BIT_OR(perm_flag) AS mask FROM role_perms GROUP BY role_id -
BIT_AND：某组中所有人**都**有该权限 →SELECT dept, BIT_AND(COALESCE(perm_mask, 0)) AS common_bits FROM users GROUP BY dept - NULL值必须用
COALESCE(perm_mask, 0)兜底，否则整组结果变NULL，后续HAVING判断全部失效
聚合结果仍是整数掩码，真正校验权限还得靠&：比如(BIT_OR(perm_flag) & 4) > 0，括号不能省——&优先级低于>。
权限系统里最常被忽略的点：位运算本身不提供语义隔离。同一个perm_mask字段既存用户权限，又存角色默认权限，若没在JOIN或WHERE里严格限定来源表，很容易跨角色污染结果。别指望BIT_OR自动去重或过滤维度——它只做位运算，不多干一件事。
