bit_and能判断“全员都开启的权限”是因为它对一列值逐行执行按位与，结果中某位为1当且仅当该列所有非null值在该位上均为1，天然实现权限交集语义；需用coalesce防null污染，且不适用于单用户鉴权（应使用perm_mask & 4 = 4）。
BIT_AND 为什么能判断“全员都开启的权限”
BIT_AND 是按位与的聚合函数，不是单次 & 运算。它对一列值逐行做 &：结果中某一位为 1，当且仅当该列**所有非 NULL 值在该位上都是 1**。这天然适合“交集”语义。
常见误用是拿它查“某个用户有没有某权限”，那是错的——应该用 perm_mask & 4 != 0，不是 BIT_AND(perm_mask, 4)。
- 正确场景：统计“所有活跃用户都启用的开关ID”，
SELECT BIT_AND(flag_mask) FROM users WHERE status = 'active' - NULL 会污染结果：
BIT_AND遇到任意 NULL 就返回 NULL，必须提前用COALESCE(flag_mask, 0)拦住 - 性能差：该函数无法利用索引，数据量超 10 万行时延迟明显，建议改用应用层遍历或预存交集值
BIT_OR 适合“至少一人开启”的汇总逻辑
BIT_OR 对整列做按位或，结果中某一位为 1，只要该列中**至少一个非 NULL 值在该位上是 1**。典型用于“系统中已启用的所有功能集合”。
例如权限后台展示“当前环境已分配的全部权限位”，就靠它一键合并：
SELECT BIT_OR(perm_mask) FROM role_permissions WHERE role_id IN (1,2,3)- 注意它不区分“谁开的”，只管“有没有人开过”，所以不能反推具体哪些角色开了哪位
- 和
BIT_AND一样，NULL 会导致整列聚合失效，必须加COALESCE - MySQL 8.0+ 支持
BIT_OR作为窗口函数，但多数旧版本只支持 GROUP BY 场景
为什么不用 AND/OR 逻辑运算符代替 BIT_AND/BIT_OR
SQL 的 AND、OR 是布尔逻辑运算符，作用于条件表达式（如 WHERE a=1 AND b=2），不是位级操作。它们不能对整列数值做位合并。
-
AND在 SELECT 列表里是语法错误：SELECT id, perm_mask AND 4 FROM t在 MySQL 中会被解释成布尔判断，返回 0/1，不是位与结果 - 真正要做单行位判断，必须用
&符号：SELECT id FROM t WHERE perm_mask & 4 - 混淆根源常来自函数名：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） - MySQL 中
(perm_mask & 4)只要非零就为真，但显式写= 4更安全，避免字段为 0 时被当成 false - SQL Server 要求严格相等：
(perm_mask & 4) = 4，而 PostgreSQL 和 SQLite 允许简写为perm_mask & 4
BIT_AND/BIT_OR 真正不可替代的场景极少，集中在权限审计、配置快照比对这类需要跨多行做位交集/并集的场合。日常 CRUD 中过度依赖它们，反而容易踩类型隐式转换和 NULL 陷阱。
