BIT_OR必须配合GROUP BY使用，否则报错Invalid use of group function；单行权限判断应使用&运算符，如WHERE (perm_flag & 4) = 4。
BIT_OR 必须和 GROUP BY 一起用，否则直接报错
MySQL 会明确拒绝 BIT_OR(perm_flag) 出现在没有 GROUP BY 的查询中，错误信息是 Invalid use of group function。这不是限制，而是语义强制：BIT_OR 的本意就是“对一组行做位或归约”，单行没意义。想查某个用户的权限？别用 BIT_OR，直接写 WHERE (perm_flag & 4) = 4。
怎么写一个安全的 BIT_OR 分组查询
典型场景是按角色汇总所有权限位。基础结构没问题，但生产环境必须加三道防护：
-
COALESCE(perm_flag, 0)：防止整组因某行为NULL导致结果为NULL - 确保分组维度完整：比如多租户系统里，只写
GROUP BY role_id会把不同租户的权限混在一起，得加上tenant_id - 字段类型必须是整型（
TINYINT、INT）；字符串如'4'会被转成4，但'0b100'或'0x4'会静默变成0
正确示例：
SELECT tenant_id, role_id, BIT_OR(COALESCE(perm_flag, 0)) AS mask<br>FROM role_perms<br>GROUP BY tenant_id, role_id;
为什么不能在 WHERE 或 HAVING 里裸用 BIT_OR 结果做权限判断
BIT_OR 输出的是掩码整数，不是布尔值。直接写 HAVING BIT_OR(perm_flag) & 4 是危险的——只要结果非零就通过，可能是无关位碰巧为 1。
真正要确认“该角色具备删除权限（bit 2 = 4）”，必须用等号校验：
- 错误：
HAVING BIT_OR(perm_flag) & 4 - 正确：
HAVING (BIT_OR(COALESCE(perm_flag, 0)) & 4) = 4
括号不能省，因为 & 优先级低于 =；等号比大于零更严格，排除了误判可能。
BIT_OR 不等于去重，也不等于计数
它只是位或：两行都是 perm_flag = 1（读权限），BIT_OR 结果仍是 1；三行分别是 1、2、4，结果是 7（二进制 0b111）。它不告诉你哪一行贡献了哪一位，也不统计出现次数。
如果需要知道“这个角色下有多少人有写权限”，得换思路：
SELECT role_id,<br> COUNT(*) FILTER (WHERE perm_flag & 2 = 2) AS writer_count<br>FROM role_perms<br>GROUP BY role_id;
（PostgreSQL 写法；MySQL 可用
SUM(IF(perm_flag & 2 = 2, 1, 0))）
最易被忽略的是 NULL 处理和租户隔离——这两个点一旦漏掉，权限结果就不可信，而且很难在测试中暴露。
