BIT_OR在MySQL中是对分组内所有非NULL整数权限掩码逐位执行按位或运算，结果某位为1当且仅当该组至少一行在该位为1；必须配合GROUP BY使用，字段须为整型且权限值应为2的幂，不可用于WHERE过滤，实际权限检查需用&运算符验证。
BIT_OR 函数在 MySQL 中的权限位聚合逻辑
MySQL 的 BIT_OR 是按位或聚合函数，适合把多个整数权限掩码合并成一个总掩码。它不是标准 SQL 函数，仅限 MySQL（8.0+ 完整支持，5.7 可用但有隐式转换风险）。它的行为是：对分组内所有非 NULL 值逐位执行 OR 运算，结果为整数；遇到 NULL 会忽略，全为 NULL 则返回 NULL。
常见错误是误以为它能“去重合并权限”，其实它只做位运算——比如用户 A 有 0b001（读），用户 B 有 0b010（写），BIT_OR 结果是 0b011（读+写）；但如果两人权限相同（都是 0b001），结果仍是 0b001，不会报错也不会去重计数。
- 必须确保列类型是整数（
TINYINT、INT等），不能是字符串或枚举，否则会静默转为 0 - 权限值应设计为 2 的幂（如 1, 2, 4, 8…），否则位或结果不可逆、无法用
&检查单个权限 - 避免在
GROUP BY中漏掉关键维度（比如只按角色分组却没考虑租户隔离），导致跨租户权限污染
典型权限表结构与 BIT_OR 查询写法
假设权限存于 user_role_permission 表，字段为 user_id、role_id、perm_flag（tinyint unsigned，值为 1/2/4/8…），要查每个角色的汇总权限掩码：
SELECT role_id, BIT_OR(perm_flag) AS combined_mask FROM user_role_permission GROUP BY role_id;
如果需关联角色名，直接 JOIN 即可；但注意：JOIN 发生在聚合前还是后会影响结果。若在聚合后 JOIN，要用子查询或 CTE；若在聚合前 JOIN，需确认 perm_flag 来源唯一且无重复行（比如多条相同 role_id+perm_flag 记录会导致冗余 OR，但结果不变）。
-
BIT_OR不支持DISTINCT，要去重必须先SELECT DISTINCT再聚合 - 不能在 WHERE 中直接用
BIT_OR，它只能出现在 SELECT 或 HAVING 子句中 - 若权限来自 JSON 数组（如
['read','write']），得先用JSON_CONTAINS+ 映射表转整数，再聚合——BIT_OR不接受 JSON 或字符串
用 & 运算符验证权限是否启用
BIT_OR 输出的是掩码，真正使用时靠位与（&）判断某权限是否存在。例如，已知 read=1、write=2、delete=4，检查 combined_mask 是否含写权限：
SELECT role_id,
BIT_OR(perm_flag) AS combined_mask,
(BIT_OR(perm_flag) & 2) > 0 AS can_write
FROM user_role_permission
GROUP BY role_id;
这里 (combined_mask & 2) > 0 是关键——不能写成 = 2，因为如果同时有 read（1）和 write（2），combined_mask 是 3，3 & 2 得 2，但若只写 = 2 就漏判了。
- 权限检查表达式必须加括号，避免运算符优先级问题（
&优先级低于=和>） - MySQL 中
TRUE对应 1，FALSE对应 0，所以> 0比= 1更安全（&结果可能是 2、4 等非 1 值） - 不要在应用层拼接 SQL 判断权限（如
"WHERE mask & " + permValue），易 SQL 注入；应预定义常量或用参数化查询
替代方案与兼容性陷阱
PostgreSQL 和 SQL Server 没有 BIT_OR，得用其他方式模拟：PostgreSQL 可用 BIT_OR()（9.4+），但名字一样、行为一致；SQL Server 要用 POWER(2, n) + SUM + CASE 手动构造，或改用 STRING_AGG + 应用层解析——性能差且难维护。
MySQL 5.7 中 BIT_OR 对 NULL 处理不严格，某些场景下可能返回 0 而非 NULL；8.0 修复了这点，但升级前务必测试空权限组的输出。
- 如果权限位超过 64 位（如用
BIGINT UNSIGNED存 64 种权限），BIT_OR仍可用，但应用层解析时要注意语言是否支持大整数（Python int 没问题，JavaScript number 会精度丢失） - 别用
SUM替代BIT_OR：SUM 在权限重复时会翻倍（两个 write=2 → sum=4），而 BIT_OR 始终是 2 - 迁移时若旧系统用字符串逗号拼接权限（如 'read,write'），不要试图用
FIND_IN_SET做聚合——那是反模式，应先清洗数据再建位图
位运算本身很快，但权限模型一旦嵌套（比如角色继承角色、权限继承权限），BIT_OR 就覆盖不了依赖关系，这时候得退回到关系型建模或引入专门的权限服务。
