可行，但需数据库支持按位与且状态字段为整型：mysql/sql server用&，postgresql用&但要求整型，sqlite需bitand()，oracle必须用bitand()；视图中宜用case解包为布尔别名并注意索引优化。
SQL视图里直接用 & 运算符筛选状态位可行吗？
可行，但必须确认数据库引擎支持按位与操作——MySQL、PostgreSQL、SQL Server 都支持 &（PostgreSQL 实际用 & 但需确保操作数为整型），而 SQLite 默认不支持（需启用扩展或改用 bitand() 函数）。Oracle 则要用 BITAND() 内置函数，不能写 &。
常见错误是把状态字段当字符串处理，比如 status = '5' 后再试图位运算，结果全为空；必须确保字段类型是整数（TINYINT、SMALLINT 或 INTEGER）。
- MySQL：直接用
status & 4 = 4表示“第 3 位（从 0 开始）为 1” - PostgreSQL：同样支持
status & 4 = 4，但若字段是TEXT，会报错operator does not exist: text & integer - SQL Server：语法一致，但注意
BITAND是 2022+ 才引入的兼容函数，老版本只认& - Oracle：必须写
BITAND(status, 4) = 4，写status & 4 = 4直接报错ORA-00920: invalid relational operator
在视图定义中封装位状态为可读列（如 is_active、is_locked）
硬编码位掩码会让视图难以维护。更稳妥的做法是在视图里用 CASE 显式解包，把位逻辑转成布尔别名：
CREATE VIEW user_summary AS
SELECT id,
name,
CASE WHEN status & 1 = 1 THEN 1 ELSE 0 END AS is_active,
CASE WHEN status & 2 = 2 THEN 1 ELSE 0 END AS is_verified,
CASE WHEN status & 4 = 4 THEN 1 ELSE 0 END AS is_locked
FROM users;
这样下游查询可以直接写 WHERE is_locked = 1，语义清晰，也避免重复计算。但要注意：这类表达式无法走索引（除非数据库支持函数索引，如 PostgreSQL 的 CREATE INDEX ON users ((status & 4))）。
- 别用
BOOLEAN类型返回（如 PostgreSQL 的status & 4 > 0返回bool），某些客户端会把TRUE/FALSE映射异常 - 位掩码值建议提取为常量注释，比如
-- 4 = LOCKED_BIT，否则半年后没人记得 8 是什么 - 如果状态位超过 32 位，MySQL 的
INT可能溢出，应改用BIGINT并确认所有位运算操作符对BIGINT支持
联合多个位条件时，& 和 OR 混用容易出错
想查“已激活且已锁定”的用户，直觉可能写 status & 1 = 1 AND status & 4 = 4，这没问题；但若想查“已激活或已锁定”，就不能写 status & (1 OR 4) = (1 OR 4)——OR 是逻辑运算，不是位或，这里会先算 1 OR 4 得到 TRUE（即 1），整个条件退化为 status & 1 = 1。
正确做法是用位或组合掩码：status & 5 = 5（因为 1 | 4 = 5），或者拆开写：(status & 1 = 1) OR (status & 4 = 4)。前者更高效，后者更易读。
- MySQL 中
1 OR 4确实返回 1（因非零即真），这不是 bug，是 SQL 逻辑运算规则 - 位或掩码要预先算好，比如“激活+验证+锁定”对应
1 | 2 | 4 = 7，别在 WHERE 里实时算1|2|4，部分数据库不支持表达式作为位运算右操作数 - PostgreSQL 对
status & 7 > 0这种“是否至少有一位匹配”的写法更友好，但语义不如= 7严格（后者要求三位全为 1）
性能关键点：位运算能走索引吗？
绝大多数情况下不能——因为 status & 4 = 4 是函数式谓词，优化器无法直接命中 status 字段的 B-tree 索引。真正高效的方案只有两个：
- 建表达式索引（PostgreSQL/SQL Server）：
CREATE INDEX idx_status_locked ON users ((status & 4)) - 冗余一个计算列并索引它（MySQL 5.7+、SQL Server）：
ALTER TABLE users ADD is_locked TINYINT AS (CASE WHEN status & 4 = 4 THEN 1 ELSE 0 END) STORED，然后给is_locked建索引
别指望优化器自动重写 status & 4 = 4 成范围扫描；也别在大表上靠位运算做高频筛选却不加索引支撑——数据量一过百万，延迟就明显了。
位运算本身很快，慢的是全表扫。最容易被忽略的，是开发时用小数据集测试没感觉，上线后才暴露索引缺失问题。
