MySQL 8.0.17+原生支持BIT_OR/BIT_AND，要求输入为整型且NULL被忽略；低版本需变量累加并显式排序；PostgreSQL用int8or()或bit(n)转换；SQL Server无内置方案，须应用层处理。
MySQL 8.0+ 才原生支持 BIT_OR 和 BIT_AND 聚合函数，低版本必须手写模拟；PostgreSQL 没这两个函数，得用 bit_or()（需先转整型）或窗口+递归；SQL Server 完全不支持位运算聚合，只能靠 FOR XML 或 CLR。
MySQL 中直接用 BIT_OR 和 BIT_AND 的前提条件
这两个函数只在 MySQL 8.0.17+ 正式可用，且要求所有输入值为整数类型（TINYINT 到 BIGINT）。传字符串会隐式转换——但风险极大：
- 字符串如
'101'会被转成十进制整数101，不是二进制位0b101 - 想对二进制字符串做位或？得先用
CONV(str, 2, 10)转成整数，再聚合 - NULL 值会被忽略；全为 NULL 时结果为
NULL，不是0
示例：把每行的权限掩码（整型）做 OR 合并
SELECT BIT_OR(permission_mask) FROM user_perms WHERE user_id = 123;
MySQL 5.7 或更早版本怎么模拟 BIT_OR
没有聚合函数，只能靠变量累加或自连接。变量法最常用，但要注意执行顺序不可靠：
- 必须用
ORDER BY显式排序，否则@acc := @acc | val结果不确定 - 初始化变量要在同一语句中完成，不能依赖上一条
SET - 聚合后还得
SELECT出最终值，不能只写赋值语句
安全写法：
SELECT @acc AS bit_or_result
FROM (SELECT @acc := 0) init,
(SELECT @acc := @acc | permission_mask
FROM user_perms
WHERE user_id = 123
ORDER BY id) calc;
PostgreSQL 怎么做位或聚合
PostgreSQL 有 bit_or() 和 bit_and()，但只接受 bit(n) 类型，不接受整数。常见错误是直接传 INT 报错：
- 报错信息：
function bit_or(integer) does not exist - 正确做法：用
CAST(val AS bit(64))或val::bit(64)转类型 - 长度选错会截断——比如
bit(8)存不下256（需要至少 9 位） - 更稳妥的是用
int4or()或int8or()聚合函数（需启用pg_catalog扩展，通常默认已装）
推荐写法：
SELECT int8or(permission_mask) FROM user_perms WHERE user_id = 123;
SQL Server 完全没内置方案，只能绕路
没有位运算聚合函数，也没有位数组类型。常见替代思路有三种，但都带缺陷：
- 用
POWER(2, n)手动建掩码再SUM——仅适用于单一位（如第 3 位），不能处理任意组合 - 用
STRING_AGG拼二进制字符串再用 CLR 或外部工具解析——运维成本高 - 最现实的是在应用层聚合：查出所有整数值，用 Python/Java 做
reduce(lambda a,b: a|b, values)
如果坚持 SQL 内解决，唯一可行的是递归 CTE 模拟循环，但性能差、可读性低，超过 100 行基本卡死。
真正麻烦的不是语法，而是不同数据库对「字符串参与位运算」的定义根本不一致：MySQL 当数字转，PostgreSQL 要先转位串，SQL Server 直接拒收。别指望写一次 SQL 跑遍三端。
