BIT_COUNT仅适合固定位数、静态权限集的轻量场景；核心权限校验必须用位运算（如user_perms & 4 > 0），BIT_COUNT仅用于统计总数或粗筛，如WHERE BIT_COUNT(user_perms) >= 3，且需配合生成列索引提升性能。
直接说结论：用 BIT_COUNT 做权限校验可行，但只适合「固定位数、静态权限集」的轻量场景；一旦权限动态增减或需要细粒度控制（比如按角色叠加、继承），它会迅速变成维护噩梦。
为什么 BIT_COUNT 能用来做权限判断
MySQL 的整型字段可以存二进制位，比如用一个 TINYINT 存 8 个开关：第 0 位表示「查看」，第 1 位表示「编辑」，第 2 位表示「删除」……那么值 5（二进制 101）就代表同时有「查看」和「删除」权限。而 BIT_COUNT(n) 返回的是 n 的二进制表示中 1 的个数——但它本身不判断「某一位是否为 1」，只是统计总数。所以单独用它做校验是错的，必须配合位运算符。
-
BIT_COUNT(user_perms & 4) > 0才表示「是否有删除权限」（假设删除对应第 2 位，即1 ） -
BIT_COUNT(user_perms)只能告诉你用户总共开了几个权限，不能回答「有没有某一项」 - 常见误用：
WHERE BIT_COUNT(perm_mask) = 3—— 这查的是「恰好开了 3 项权限」，不是「包含这 3 项」
真正校验单个权限：用 & 和 > 0 判断位是否存在
权限校验的核心不是数有几个 1，而是确认某一位是否被置为 1。MySQL 提供了标准位与操作符 &，这是唯一可靠的方式。
- 假设权限定义：查看=1（
1 ）、编辑=2（<code>1 ）、删除=4（<code>1 ）、导出=8（<code>1 ） - 检查用户是否有「编辑」权限：
user_perms & 2 > 0 - 检查是否同时拥有「查看」和「导出」：
(user_perms & 1) > 0 AND (user_perms & 8) > 0 - 注意：不要写成
user_perms & 2 = 2，虽然结果一样，但语义不清；> 0更直观表达「该位被启用」
BIT_COUNT 的合理用途：统计权限总数或做粗筛
它真正的价值在聚合分析和前置过滤，而不是核心校验逻辑。
- 查「至少开通 3 项权限的用户」：
WHERE BIT_COUNT(user_perms) >= 3 - 配合应用层做快速分级：比如
BIT_COUNT(user_perms) = 1的用户走简化 UI 流程 - 排查异常数据：发现某用户
BIT_COUNT(user_perms) > 8（超出预设最大权限数），说明可能写入了非法值 - 性能提示：对大表执行
BIT_COUNT()无法使用索引，若频繁用于 WHERE 条件，要考虑加生成列 + 索引，例如：ALTER TABLE users ADD COLUMN perm_count TINYINT AS (BIT_COUNT(user_perms)) STORED;
CREATE INDEX idx_perm_count ON users(perm_count);
最常被忽略的一点：位运算依赖严格的权限位定义同步。如果应用代码里把「审核」定义为 16，而数据库迁移脚本漏掉了更新注释或文档，后续排查权限失效时，没人会先想到去翻二进制位映射表。
