在权限管理系统中，我们常使用位运算来设计权限掩码，每个权限对应一个二进制位，用户的总权限是所有拥有权限的位或结果。当需要筛选拥有特定权限的用户时，结合SQL嵌套查询和位运算可以快速得到结果，避免复杂的多表关联操作。
权限掩码的基本设计
首先我们需要明确权限掩码的设计规则，假设系统有4个基础权限，每个权限对应一个2的幂次值：
- 查看权限：1（二进制0001）
- 新增权限：2（二进制0010）
- 编辑权限：4（二进制0100）
- 删除权限：8（二进制1000）
如果用户拥有查看和编辑权限，那么他的权限掩码值就是1 | 4 = 5（二进制0101）。
位运算筛选权限的核心逻辑
判断用户是否拥有某个特定权限，只需要用用户的权限掩码和该权限的值做按位与运算，如果结果等于该权限值，说明用户拥有这个权限。例如用户权限掩码是5，判断是否有编辑权限：5 & 4 = 4，等于编辑权限的值，说明拥有该权限。
嵌套查询结合位运算的实现示例
假设我们有用户表user，结构如下：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 用户ID |
| username | varchar(50) | 用户名 |
| permission_mask | int | 权限掩码 |
场景1：筛选拥有编辑权限的所有用户
我们可以直接使用位运算筛选，也可以结合嵌套查询处理更复杂的场景，比如先过滤出状态正常的用户，再从中筛选拥有编辑权限的用户：
-- 嵌套查询实现：先筛选状态正常的用户，再判断是否有编辑权限
SELECT
id,
username,
permission_mask
FROM
(
-- 内层查询：筛选状态正常的用户，假设用户表有status字段，1表示正常
SELECT
id,
username,
permission_mask
FROM
user
WHERE
status = 1
) AS normal_user
WHERE
-- 编辑权限对应的值是4，按位与结果等于4说明拥有该权限
normal_user.permission_mask & 4 = 4
场景2：筛选同时拥有查看和编辑权限的用户
需要同时判断两个权限，只需要将两个权限值做按位或，再和用户掩码做按位与运算：
-- 查看权限1，编辑权限4，合并权限值为1|4=5
SELECT
id,
username,
permission_mask
FROM
user
WHERE
permission_mask & 5 = 5
场景3：结合角色表做嵌套查询筛选
如果用户权限是关联角色表获取的，需要先通过嵌套查询得到每个用户的总权限掩码，再做筛选：
-- 假设角色表role有permission_mask字段，用户角色关联表user_role
SELECT
u.id,
u.username,
total_permission.total_mask
FROM
user u
-- 内层嵌套查询：计算每个用户的总权限掩码
INNER JOIN (
SELECT
ur.user_id,
-- 按位或聚合所有角色的权限掩码
BIT_OR(r.permission_mask) AS total_mask
FROM
user_role ur
INNER JOIN
role r ON ur.role_id = r.id
GROUP BY
ur.user_id
) AS total_permission ON u.id = total_permission.user_id
WHERE
-- 筛选拥有删除权限（值8）的用户
total_permission.total_mask & 8 = 8
注意事项和性能优化
使用这种方案时需要注意以下几点：
- 权限掩码字段建议添加索引，虽然位运算本身无法直接使用索引，但如果嵌套查询的内层有范围筛选，索引可以提升内层查询的效率
- 权限数量不建议过多，因为int类型最多支持32位，bigint最多支持64位，超过这个数量需要更换存储方案
- 位运算的优先级低于比较运算，所以条件中一定要加括号，避免逻辑错误
这种方案适合权限数量不多、权限判断逻辑简单的场景，相比多表关联判断权限的方式，代码更简洁，执行效率也更高。