在业务系统中，经常用一个整型字段存储多个布尔状态，比如订单状态、用户权限等，每一位代表一种开关。如果直接在外层SQL里写复杂的位运算条件，不仅可读性差，还容易因为魔法数字导致维护困难。通过数据库视图把位运算逻辑封装起来，可以让状态筛选变得直观且高效。
为什么要用视图封装位运算
假设有一张用户表，其中permissions字段使用不同的位表示不同权限：第0位代表可读，第1位代表可写，第2位代表可删除。如果每次查询都写permissions & 4来判断删除权限，其他开发者很难一眼看懂。而且当位定义变更时，所有散落的SQL都要同步修改。
使用视图后，可以把这些位运算转换成有意义的列名。视图本身不存储数据，只是在查询时动态计算，因此不会带来额外的写入开销，却极大提升了上层SQL的表达力。同时，视图能够统一口径，避免不同模块对同一个状态位使用不同的判断方式。
MySQL中的视图与位运算示例
在MySQL里，按位与运算符是&。我们可以创建一个视图，将权限字段拆分为多个布尔列：
CREATE TABLE user_account ( id INT PRIMARY KEY, name VARCHAR(50), permissions INT NOT NULL ); INSERT INTO user_account VALUES (1, 'alice', 5), -- 二进制 101：可读、可删除 (2, 'bob', 6); -- 二进制 110：可写、可删除 CREATE VIEW v_user_permission AS SELECT id, name, permissions, (permissions & 1) AS can_read, (permissions & 2) AS can_write, (permissions & 4) AS can_delete FROM user_account;
上面的视图中，can_read、can_write、can_delete实际上是整数值（0或非0）。在MySQL里，非0即视为真，所以可以直接用于WHERE条件。
基于视图的查询就非常自然了：
-- 查找拥有删除权限的用户 SELECT id, name FROM v_user_permission WHERE can_delete = 4; -- 查找可读且可写的用户（注意位运算组合） SELECT id, name FROM v_user_permission WHERE (permissions & 3) = 3;
这里需要说明，can_delete = 4是因为permissions & 4结果要么是0要么是4。如果希望返回真正的布尔类型，可以用CASE表达式，但多数场景下整数判断已经足够清晰。
PostgreSQL中的处理方式
PostgreSQL同样支持&运算符，并且位串类型（bit）也很适合处理状态位。不过在视图里用整数按位与最为通用：
CREATE TABLE user_account ( id SERIAL PRIMARY KEY, name TEXT, permissions INT NOT NULL ); CREATE VIEW v_user_permission AS SELECT id, name, permissions, (permissions & 1) > 0 AS can_read, (permissions & 2) > 0 AS can_write, (permissions & 4) > 0 AS can_delete FROM user_account;
在PostgreSQL中，布尔类型更规范，所以使用> 0将结果转成真正的boolean。这样在查询时就能写WHERE can_delete，而不用比较数值。
如果状态位非常多，也可以借助get_bit函数，但视图内直接写按位与性能更好，也更容易被优化器识别。对于频繁使用的筛选，还可以考虑在视图之外建立表达式索引，例如CREATE INDEX ON user_account ((permissions & 4))，进一步提升筛选速度。
SQL Server里的实现差异
SQL Server也提供&运算符，但视图内位运算的写法与MySQL类似，只是布尔表达需要用CASE或比较来显式转换：
CREATE TABLE user_account ( id INT PRIMARY KEY, name NVARCHAR(50), permissions INT NOT NULL ); CREATE VIEW v_user_permission AS SELECT id, name, permissions, CASE WHEN (permissions & 1) <> 0 THEN 1 ELSE 0 END AS can_read, CASE WHEN (permissions & 2) <> 0 THEN 1 ELSE 0 END AS can_write, CASE WHEN (permissions & 4) <> 0 THEN 1 ELSE 0 END AS can_delete FROM user_account;
SQL Server的查询优化器对视图的处理相对严格，尤其是索引视图（物化视图）不允许使用非确定性函数，但简单的位运算是确定性的，因此在普通视图中毫无问题。如果使用了索引视图，需注意位运算仍不能出现在索引键定义中，除非先持久化计算列。
此外，SQL Server中常配合BIT类型做标志位，但如果已经用整型压缩存储，视图就是最轻量的解耦层。上层报表或接口只认can_write这类列，底层改位定义时只需改视图，不影响业务SQL。
性能与维护上的建议
视图本身不解决索引问题，如果状态位筛选非常频繁且数据量大，建议在基表上建立基于表达式的索引，或者在视图外再包一层带WITH SCHEMABINDING的约束。不过对绝大多数系统来说，视图带来的可读性提升远大于微小的解析开销。
另一个常见误区是把所有状态位都拆成独立列后，又用SELECT *查询视图，导致返回大量冗余计算列。应当只选取需要的列，并保持位定义文档与视图代码同步。只要遵循这些原则，SQL视图配合位运算就能优雅地实现状态位的高效筛选。