如何在SQL中使用BIT_OR或BIT_AND进行二进制分组聚合？-SQL-PHP中文网

bit_or和bit_and是按位聚合函数，非数值求和：bit_or(1,2,4)得7（0111），bit_or(3,3)仍为3；bit_and求所有行对应位全为1的交集，二者均需防null且仅适用于权限、状态等位图场景。

如何在sql中使用bit_or或bit_and进行二进制分组聚合？

BIT_OR 和 BIT_AND 是什么，为什么不能直接当 SUM 用？

它们是位运算聚合函数，不是数值累加。比如 BIT_OR(1, 2, 4) 得到 7（二进制 0111），因为把各数对应位“或”起来；而 SUM(1, 2, 4) 是 7 只是巧合，BIT_OR(3, 3) 还是 3（二进制 011 | 011 = 011），但 SUM(3, 3) 是 6。误当求和用会悄悄出错。

什么时候该用 BIT_OR 而不是 GROUP_CONCAT？

当你在做权限、状态、开关类标记的合并时——比如用户有多个角色，每个角色用一个 bit 表示（管理员=1，编辑=2，审核员=4），想快速知道某组用户 collectively 拥有哪些权限，BIT_OR(role_flag) 一行就搞定；用 GROUP_CONCAT 得到字符串 "1,2,4"，后续还得解析、去重、转数字，没法直接参与位判断。

适用场景：权限掩码、功能开关组合、状态位图（如文件属性：只读=1、隐藏=2、系统=4）
不适用场景：需要保留原始值个数、顺序、重复信息时
注意 MySQL 5.7+ 才支持窗口函数形式的 BIT_OR()，8.0+ 更稳定；MariaDB 10.3+ 支持，但旧版可能只有 BIT_OR() 作为聚合函数，不支持表达式参数

常见错误：NULL 值让整个 BIT_OR 结果变 NULL

只要分组里有一个 role_flag 是 NULL，BIT_OR(role_flag) 就返回 NULL，哪怕其他全是非空整数。这不是 bug，是 SQL 标准行为（聚合函数对 NULL 敏感）。修复方法很简单：

用 COALESCE(role_flag, 0) 把 NULL 转成 0（不影响位或结果）
或者加 WHERE role_flag IS NOT NULL 过滤掉无效行
别用 IFNULL(role_flag, 0) —— 它在某些老版本 MySQL 中可能触发隐式类型转换，导致位运算异常

示例：

SELECT user_group, BIT_OR(COALESCE(role_flag, 0)) AS combined_flags
FROM user_roles
GROUP BY user_group;

BIT_AND 的陷阱：它求的是“所有成员共同拥有的位”，不是“并集”

BIT_AND 容易被名字误导。比如三个人的权限分别是 7（0111）、3（0011）、5（0101），BIT_AND 结果是 1（0001）——只有第 0 位在三个数中都为 1。这适合找交集场景（如“这个组里所有人都具备的功能”），但绝不是“汇总所有功能”。

典型用途：检查一组记录是否全部开启某个开关（比如 BIT_AND(status & 8) > 0 判断是否全为“已归档”）
性能注意：BIT_AND 和 BIT_OR 都是 O(n) 扫描，无索引加速；大数据量下别在没 WHERE 的大表上直接跑
兼容性提醒：PostgreSQL 没原生 BIT_AND/BIT_OR 聚合，得用 bool_and(bool_or()) 组合模拟，或自定义聚合函数

真正难的不是写法，是确认业务语义到底要“并集”还是“交集”，以及是否允许 NULL 干扰结果——这两个点漏掉，查出来的数据看着像对，其实已经错了。