BIT_AND和BIT_OR只能在GROUP BY中使用，是对分组内多行值逐位聚合的函数，不可用于WHERE过滤；误用如WHERE BIT_AND(status)=1会报错，正确用法是SELECT cate, BIT_AND(flags) FROM products GROUP BY cate。
BIT_OR和BIT_AND只能在GROUP BY里用
这两个函数不是单行过滤工具，而是跨行逐位聚合操作符。常见错误是直接塞进WHERE：比如WHERE BIT_AND(status) = 1，MySQL会立刻报Invalid use of group function。它们必须配合GROUP BY使用，语义是“对每组内的所有值，按位做与/或运算”。
典型场景是统计某类资源的共性或并集状态：
-
SELECT cate, BIT_AND(flags) AS common_flags FROM products GROUP BY cate→ 找出每个品类下所有SKU都具备的状态位 -
SELECT user_id, BIT_OR(permission_mask) FROM user_perms GROUP BY user_id→ 合并用户所有权限记录，得到最终掩码
MySQL 5.7之前怎么模拟BIT_OR
老版本没有内置聚合位运算函数，只能靠用户变量+显式排序硬凑。但执行顺序不可靠，漏掉ORDER BY会导致结果随机。
安全写法必须在同一语句中完成初始化、累加、输出三步：
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;
注意点：
- 不能分开写
SET @acc = 0再查，变量作用域不保证延续 -
ORDER BY必须显式指定，否则@acc := @acc | val的执行顺序由优化器决定 - 最终要
SELECT @acc显式取值，只赋值不输出会返回空结果集
PostgreSQL和SQL Server的位聚合差异
PostgreSQL原生支持bit_or()，但只认bit(n)类型，传整数会报function bit_or(integer) does not exist。得先转类型：
SELECT int8or(permission_mask) FROM user_perms WHERE user_id = 123;
SQL Server则完全没内置方案。常见绕路方式都有硬伤：
- 用
SUM(POWER(2, n))手动建掩码 → 只能处理固定位，无法应对任意组合 - 用
STRING_AGG拼二进制字符串再CLR解析 → 运维成本高，上线阻力大 - 最现实的是查出所有整数值，在应用层用
reduce(lambda a,b: a|b, values)聚合
字符串字段做位聚合前必须转整型
如果权限掩码存的是字符串（比如'12'），直接BIT_OR()会静默转成0，结果全空——这不是bug，是MySQL隐式转换规则。
正确做法是先用CONV(str, 2, 10)或CAST(str AS UNSIGNED)转整数，再聚合：
SELECT BIT_OR(CAST(mask_str AS UNSIGNED)) FROM user_perms WHERE user_id = 123;
特别注意：
- 字符串内容必须是合法数字，
'0b1100'这种二进制字面量不被识别 - 若原始数据是二进制字符串（如
'1100'），得用CONV(mask_str, 2, 10)转十进制整数 - NULL值会被忽略，但全为NULL时结果是NULL，不是0，业务代码得判空
实际用的时候，最容易被忽略的是字段类型和NULL处理——聚合前不校验类型，结果就 silently 错；不处理NULL，下游逻辑可能崩。
