BIT_OR只能用于分组聚合，不能替代单行权限判断；它必须配合GROUP BY使用，否则报错“Invalid use of group function”，输入须为整数且权限值应为2的幂，最终权限校验需用&运算符。
BIT_OR 只能用于分组聚合，不能替代单行权限判断；它输出的是掩码整数，真正校验权限还得靠 & 运算符。
BIT_OR 必须配合 GROUP BY 使用，否则直接报错
MySQL 会拒绝任何未带 GROUP BY 的 BIT_OR() 调用，报错信息是 Invalid use of group function。这不是语法糖，而是语义强制：它天生就是跨行归约的，不是单值函数。
- 错误写法：
SELECT BIT_OR(perm_flag) FROM user_perms WHERE user_id = 123（没GROUP BY，报错） - 正确写法：
SELECT role_id, BIT_OR(perm_flag) AS mask FROM user_perms GROUP BY role_id - 若只想查一个角色，仍需
GROUP BY：SELECT BIT_OR(perm_flag) FROM user_perms WHERE role_id = 5 GROUP BY role_id - 想在聚合后加条件筛选？用
HAVING，不是WHERE：HAVING BIT_OR(perm_flag) & 4 = 4
输入必须是整数，字符串或 NULL 会静默破坏结果
BIT_OR 对非整数类型不做提醒，只按 MySQL 隐式转换规则处理——这在生产环境极易引发权限“消失”。
- 字段是
VARCHAR类型（如存'read'或'2'）？BIT_OR会把'2'当成整数 2，但把'read'转成 0，整列权限变空 - 字段含
NULL？BIT_OR自动跳过，但若整组全为NULL，结果返回NULL而非 0，后续&判断全失效 - 安全写法：
BIT_OR(COALESCE(perm_flag, 0))，确保无NULL干扰 - 权限值必须是 2 的幂（1, 2, 4, 8…），否则
&校验无法准确分离单个权限位
权限校验不能只靠 BIT_OR 输出，& 才是最终执行者
BIT_OR 只负责“汇总有哪些权限被分配过”，不回答“某用户是否拥有某权限”。这个动作必须由应用层或 SQL 中的位与运算完成。
- 假设
read=1、write=2、delete=4，BIT_OR返回 3（即0b11），说明该组至少有人有读+写权限 - 但你要查“这个角色能否删除”，得写：
(BIT_OR(perm_flag) & 4) > 0，括号不能省（&优先级低于=和>） - 检查“同时具备读和写”：
(BIT_OR(perm_flag) & 3) = 3（因为 1|2=3） - 注意：这里判断的是“该角色组整体是否覆盖此权限”，不是“每个成员都具备”——那是
BIT_AND的事
跨数据库兼容性极差，别默认它存在
MySQL 8.0.17+ 是唯一原生支持 BIT_OR 的主流数据库；其他系统要么换函数名，要么根本没实现。
- PostgreSQL：没有
BIT_OR，用int8or(perm_flag)（推荐）或bit_or(perm_flag::bit(64))（需指定长度防截断） - SQL Server：无等价函数，
POWER(2,n)+SUM只能硬编码固定位，实际项目中基本都在应用层做reduce(lambda a,b: a|b, perms) - Databricks：用
bitmap_or_agg()，但输入是BINARY，不是整数，语义不同 - 如果代码要跨库运行，别碰
BIT_OR，改用MAX(CASE WHEN ... THEN 1 ELSE 0 END)模拟“是否存在”更稳妥
最常被忽略的一点：BIT_OR 不解决权限来源冲突。比如两个角色都给了 write 权限，BIT_OR 结果仍是 2，不会告诉你重复了；它只管“位有没有被置起”，不管“谁置的、置了几次”。真要审计权限分配路径，得回溯原始明细行，而不是依赖聚合结果。
