位运算必须放在外层where或on中，子查询仅负责取值；若在子查询where中使用位运算，会导致语法错误、类型陷阱或性能崩溃。
嵌套查询里直接用位运算做权限筛选，基本等于自找麻烦——WHERE子句中嵌套SELECT再套&，不仅语义混乱、性能崩坏，还极大概率触发语法错误或隐式类型转换陷阱。
为什么不能在子查询的 WHERE 里写 (perm & 1) = 1
MySQL/PostgreSQL/SQL Server 都不支持在子查询的 WHERE 条件中对聚合结果或外部引用字段做位运算过滤（除非该字段来自外层 FROM），更别说嵌套层级一深，优化器连执行计划都懒得生成。常见报错包括：Invalid use of group function（误用聚合）、Unknown column in 'where clause'（列作用域错误）、或干脆返回空结果但无提示。
- 子查询若含
GROUP BY，就不能在WHERE里用BIT_AND()等函数——必须改用HAVING - 若子查询返回单值（如
(SELECT MAX(perm) FROM roles WHERE user_id = u.id)），外面再套WHERE (subquery & 4) = 4理论可行，但 MySQL 8.0 前会因子查询不能出现在WHERE右侧而报错 - SQL Server 对标量子查询参与位运算更敏感，常因数据类型隐式转成
int失败而中断
真要嵌套 + 位运算，只有一种安全姿势：把位判断移到外层 WHERE
让子查询只负责“取值”，位运算逻辑全部放在外层查询的 WHERE 或 ON 中。例如查“属于某角色组、且该角色具备删除权限”的用户：
SELECT u.* FROM users u INNER JOIN ( SELECT user_id, role_mask FROM user_roles WHERE role_type = 'admin' ) r ON u.id = r.user_id WHERE (r.role_mask & 4) = 4;
- 子查询
r只输出user_id和原始整数role_mask，不做任何计算 - 位判断
(r.role_mask & 4) = 4放在外层WHERE，确保字段可索引（哪怕索引无效，至少语法合法） - 若需多条件组合，比如“有读+写，且不属于禁用组”，应拆成多个
JOIN或用EXISTS，而非堆在子查询WHERE里
替代方案：用 EXISTS + 位运算，比嵌套查询更稳也更易读
当目标是“用户满足某类权限组合”时，EXISTS 天然适合表达“存在一个满足位条件的关联记录”，避免子查询值传递和类型风险：
SELECT * FROM users u
WHERE EXISTS (
SELECT 1 FROM user_roles ur
WHERE ur.user_id = u.id
AND ur.role_type = 'editor'
AND (ur.mask & 3) = 3 -- 同时有读(1)和写(2)
);
-
EXISTS子句内可自由使用&、=、括号，无需担心返回值类型 - 数据库能更好下推条件（如先过滤
role_type再做位判断） - 比
IN (SELECT ...)更安全：子查询空时不导致主查询全空，语义更准确 - 注意：若
user_roles.mask是TINYINT UNSIGNED但实际存了超 255 的值，MySQL 会静默截断——务必确认字段类型足够（推荐INT UNSIGNED）
位运算本身没问题，问题出在把它塞进嵌套查询的错误位置。真正卡住性能和正确性的，从来不是 & 这个符号，而是你让它在哪一层求值、对哪个类型的值求值、以及有没有给它留好括号和类型空间。
