BIT_AND是按位交集聚合函数，对分组内非NULL整数逐位AND运算，结果某位为1当且仅当该组每行对应位均为1；需配合GROUP BY使用，常用于全员权限位判断。
BIT_AND不是布尔判断，而是按位归约
BIG_AND 对分组内所有非 NULL 整数值执行逐位 & 运算，结果某一位为 1 ⇔ 该组**每一行**在该位上都为 1。它不返回 true/false，也不统计“有多少行满足条件”，只做位级交集。
常见错误现象：
- 把
BIT_AND(status)当成 “是否全员为真” —— 实际上BIT_AND(1,1,0)得 0，BIT_AND(1,1,1)才得 1，和布尔逻辑完全不同 - 字段含
NULL时整组结果变NULL，导致HAVING BIT_AND(status) & 4 = 4不成立（因为NULL = 4是未知）
正确做法：
- 用
COALESCE(status, 0)拦住 NULL，避免整组失效 - 确认字段类型是整型（
TINYINT、INT等），字符串会静默转十进制，比如'101'变成 101 而非二进制 5 - MySQL 8.0.17+ 支持，老版本、PostgreSQL、SQL Server 均无原生等价物
必须配合 GROUP BY，不能直接用于 WHERE 过滤
BIT_AND 是聚合函数，单独写 WHERE BIT_AND(perm_mask) & 4 = 4 会报错：Invalid use of group function。它只能出现在 SELECT 或 HAVING 子句中，且必须有对应 GROUP BY。
典型用法场景：
- 查“每个部门中全员都启用的权限位”：
SELECT dept, BIT_AND(COALESCE(perm_mask, 0)) AS common_bits FROM users GROUP BY dept - 在
HAVING中进一步筛选：HAVING BIT_AND(COALESCE(perm_mask, 0)) & 4 = 4表示该组所有行 bit 2 都为 1 - 别写
HAVING BIT_AND(perm_mask) & 4 > 0—— 这只要结果非零就通过，可能只是某无关位碰巧为 1
单行权限检查别用 BIT_AND，用 & 运算符
95% 的生产权限校验根本不用 BIT_AND，而是直接在 WHERE 中用 & 判断单个用户的掩码值。
关键细节：
- 括号不能省：
WHERE (perm_mask & 4) = 4，因为&优先级低于= - 查“同时有读（bit 0 = 1）和写（bit 1 = 2）”：
WHERE (perm_mask & 3) = 3（1 | 2 = 3） - 查“有读或删除（bit 0 和 bit 2）”：
WHERE (perm_mask & 5) != 0（1 | 4 = 5） -
BIT_AND无法走索引，大数据量分组性能差；而单行&查询可配合索引优化
金仓 KingbaseES 支持但行为与 MySQL 几乎一致
KingbaseES 也提供 BIT_AND 和 BIT_OR 聚合函数，语义和 MySQL 完全相同：对非空整数值逐位运算，全空则返回 NULL。
注意点：
- 同样要求输入为整型，字符串隐式转换规则一致（
'100'→ 十进制 100） - 同样需
COALESCE(expr, 0)处理 NULL，否则整组结果不可靠 - 不支持窗口函数形式，仍需显式
GROUP BY - 和 PostgreSQL/Oracle/SQL Server 不同——后三者要么不支持，要么需自定义或绕路实现
真正容易被忽略的是：BIT_AND/BIT_OR 的结果本身是整数，后续位判断（如 & 4 = 4）仍要手动写，函数不自动输出布尔值；而且一旦字段类型或 NULL 处理出错，结果无声失效，很难 debug。
