bit_and和bit_or仅用于分组聚合权限交集或并集，单用户权限检查必须用&运算符；bit_and返回每组所有行对应位全为1的结果，bit_or返回至少一行对应位为1的结果，二者均需coalesce防null，且不可替代单行位运算。
BIT_AND 和 BIT_OR 本身不直接用于权限判断，它们只在“统计多用户/多角色的权限交集或并集”时才有意义；单个用户的权限检查必须用 & 运算符，不是聚合函数。
BIT_AND 为什么能查“全员都开启的权限”
它对分组内所有非 NULL 的整数值逐位执行 & 运算：结果某一位为 1 ⇔ 该组**每一行**在该位上都是 1。
- 典型用途：查“当前部门所有活跃用户都启用的功能开关”，
SELECT dept, BIT_AND(flag_mask) FROM users WHERE status = 'active' GROUP BY dept - 必须加
COALESCE(flag_mask, 0)，否则任意一行是 NULL 就让整组结果变 NULL - 不能用于“用户 A 是否有权限”，
WHERE BIT_AND(perm_mask) & 4是语法错误（没GROUP BY）且语义错乱 - 性能差：无法走索引，10 万行以上分组延迟明显
BIT_OR 适合汇总“至少一人启用的状态”
它对分组内所有非 NULL 值逐位执行 | 运算：结果某一位为 1 ⇔ 该组**至少一行**在该位上是 1。
- 典型用途：查“角色 1、2、3 合并后共开通了哪些权限位”，
SELECT BIT_OR(perm_mask) FROM role_permissions WHERE role_id IN (1,2,3) - 同样要防 NULL：
BIT_OR(COALESCE(perm_mask, 0))，否则全 NULL 组返回 NULL 而非 0 - 它不告诉你“谁开了哪位”，只回答“有没有人开过”，所以不能反向推导具体权限分配
- MySQL 8.0+ 支持作为窗口函数，但旧版本只能配合
GROUP BY
为什么不能用 AND/OR 替代 BIT_AND/BIT_OR
AND 和 OR 是布尔逻辑运算符，作用于条件表达式（如 WHERE a=1 AND b=2），不是位级操作。它们不能对整列数值做位合并。
-
SELECT id, perm_mask AND 4 FROM t在 MySQL 中被解释成布尔判断，返回 0 或 1，不是位与结果 - 单行位检测必须用
&：WHERE (perm_mask & 4) = 4（括号不能省，&优先级低于=） - 聚合场景下写
WHERE BIT_AND(status) = 1直接报错：Invalid use of group function - 混淆根源常来自函数名——
BIT_AND不是“对布尔值做 AND”，而是“对整数各位做 AND 聚合”
真正高频的权限写法其实是单行 & 运算
生产环境里 95% 的权限检查根本没用到 BIT_AND 或 BIT_OR，而是直接用 & 判断单个用户的掩码值。
- 查“用户是否有删除权限”：
SELECT * FROM users WHERE id = 123 AND (perm_mask & 4) = 4 - 查“同时有读和写权限”：
WHERE (perm_mask & 5) = 5（因为1 | 4 = 5） - 查“有读或删除权限（至少一个）”：
(perm_mask & 5) != 0 -
BIT_COUNT(perm_mask)可用于统计用户开启了几个权限位，但不参与鉴权逻辑
最容易被忽略的一点是：BIT_AND/BIT_OR 的结果是整数，你仍需用 & 去提取其中某一位——比如 BIT_AND(flags) & 4 = 4 才表示“bit 2 全员开启”，光看聚合结果数字毫无业务意义。
