在数据库权限体系里，表和视图是两个不同层级的对象。很多敏感数据查询如果直接开放基础表，攻击者只要拿到一次查询权限，就能把整列或全表拖走。行级加密并不是把每一行用 AES 加密后存成密文，那种做法在联机查询和索引条件下代价很高。更实用的方案是用视图作为唯一入口，结合 CASE WHEN 表达式在返回结果前就完成按行、按列的动态替换。也就是说，同一个查询语句，不同登录用户看到的行数和字段内容可以完全不同。
一、视图为什么适合承担行级安全职责
如果把基础表直接授权给业务账号，权限管理会变得非常分散。比如员工表里有薪资、手机号、身份证号等敏感列，业务系统只需要其中一部分字段，但直接授权整表后，任何一个拥有查询权限的开发人员都可以拉取全部数据。视图在这里起到两层作用：第一层是列裁剪，只暴露必要字段；第二层是行过滤，通过视图内部的 WHERE 条件限定数据范围。这两层控制都发生在数据库端，不依赖应用代码是否记得拼接过滤条件。
另一个容易被忽视的好处是，视图可以集中修改权限逻辑。假设公司有了新的数据分级要求，需要对经理层隐藏部分薪资明细，直接调整视图定义就能生效，不需要改动所有调用该表的存储过程、报表和接口。对于多租户系统，每个租户对应一个视图或者一个带有租户过滤条件的视图，能够大幅降低跨租户数据串读的风险。视图本身不存储数据，只保存查询逻辑，因此修改成本很低，维护起来比在每张表上加触发器或额外的权限中间表更轻量。
视图也并非万能，它不能替代字段级加密和传输加密。视图只能控制用户通过 SQL 查询看到什么数据，如果攻击者获得了底层表的直接访问权限，视图就形同虚设。所以在使用视图做行级安全时，必须同时回收基础表的直接查询权限，只授予视图的访问权限。这样才能让 CASE WHEN 和行过滤条件真正成为数据出口的守门员。
二、用CASE WHEN实现列级遮蔽
CASE WHEN 在视图中最常见的用法是根据当前登录用户或者角色，返回不同形态的字段值。比如同一个员工表，HR 人员可以查看完整手机号，普通经理只能看到打码后的手机号，其他人员则只能看到空值。下面这个 SQL Server 示例定义了 v_employee_safe 视图，手机号根据 USER_NAME() 的返回值做三种处理。
CREATE VIEW v_employee_safe AS
SELECT
emp_id,
emp_name,
dept_id,
CASE
WHEN USER_NAME() = 'hr_manager' THEN phone
WHEN USER_NAME() = 'dept_manager' THEN
CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4))
ELSE NULL
END AS phone,
CASE
WHEN USER_NAME() = 'hr_manager' THEN salary
WHEN USER_NAME() = 'dept_manager' AND dept_id = 3 THEN salary
ELSE NULL
END AS salary
FROM employees;这段逻辑中，CASE WHEN 不仅做了列级遮蔽，还结合了行级条件。dept_manager 只有在查看 dept_id 为 3 的员工时才能看到薪资，其他部门的薪资直接返回 NULL。需要注意的是，这种遮蔽属于动态数据遮蔽，并没有真正改变存储在表中的数据。数据仍然以明文形式保存在基础表里，只是视图在读取数据后根据登录用户进行了二次加工。如果业务要求静态加密，应当使用数据库自带的列级加密功能，或者在应用写入前完成加密。
MySQL 的视图定义类似，只是获取当前用户的函数不同。MySQL 可以使用 CURRENT_USER() 或者 USER()，但要注意 USER() 返回的是客户端连接时指定的用户名，CURRENT_USER() 返回的是认证后的权限用户。在生产环境中建议使用 CURRENT_USER()，因为它更贴近权限判断的实际主体。PostgreSQL 则使用 current_user 这个系统变量，不过 PostgreSQL 中 CURRENT_USER 也是可用的，只是大小写处理有差异。下面是一个 PostgreSQL 版本的视图，逻辑与前面一致，但函数名不同。
CREATE VIEW v_employee_safe AS
SELECT
emp_id,
emp_name,
dept_id,
CASE
WHEN current_user = 'hr_manager' THEN phone
WHEN current_user = 'dept_manager' THEN
substring(phone from 1 for 3) || '****' || substring(phone from 8)
ELSE NULL
END AS phone,
CASE
WHEN current_user = 'hr_manager' THEN salary
WHEN current_user = 'dept_manager' AND dept_id = 3 THEN salary
ELSE NULL
END AS salary
FROM employees;两个示例都把敏感列的返回逻辑集中到一个 SQL 表达式中，应用层完全不需要知道遮蔽规则。即使某个接口忘记调用脱敏函数，从视图查询出来的数据已经是处理过的版本。对于字段特别多的场景，可以把每个敏感列都套一层 CASE WHEN，虽然视图定义会变长，但可读性仍然优于分散在多个服务里的脱敏代码。
三、读取当前用户做行级过滤
列级遮蔽解决的是某个字段看不看得全的问题，行级过滤解决的是哪些行根本不能出现的问题。比如多租户系统里，用户只能看到自己租户的数据，即使 SQL 语句没有加 WHERE，视图也必须强制加上租户条件。SQL Server 提供了 SESSION_CONTEXT 函数来读取当前会话的自定义键值对，这比直接用登录名更适合传递业务上的租户 ID。先通过 sp_set_session_context 设置 tenant_id，再在视图中读取。
CREATE VIEW v_order_tenant_safe AS
SELECT
order_id,
customer_name,
order_amount,
tenant_id
FROM orders
WHERE tenant_id = CAST(SESSION_CONTEXT(N'tenant_id') AS INT);这种写法的好处是租户 ID 不需要从应用层拼接进每一条 SQL，减少了拼接错误和 SQL 注入面。不过 SESSION_CONTEXT 需要应用在建立连接后主动设置，如果忘了设置，CAST 会得到 NULL，WHERE 条件会过滤掉所有行，导致查询结果为空。可以在应用连接池的统一初始化逻辑里设定，也可以使用 LOGON 触发器自动根据登录用户设置会话上下文。MySQL 没有 SESSION_CONTEXT，可以通过用户自定义变量传递租户 ID，比如在连接池初始化时执行 SET @tenant_id = 101，然后视图里使用 @tenant_id 做过滤。
行级过滤还可以结合数据库自身的行级安全策略。PostgreSQL 的 RLS（Row Level Security）是原生能力，允许通过 CREATE POLICY 定义行级访问规则，视图只是其中一个辅助入口。例如给 orders 表开启 RLS，然后创建策略 USING (tenant_id = current_setting('app.tenant_id')::int)。这样即使用户直接查询基础表，也会被 RLS 拦截。相比纯视图方案，RLS 更难被绕过，因为它作用在表级别。不过 RLS 策略管理起来较复杂，在不支持 RLS 或者业务逻辑需要频繁变动时，视图加 CASE WHEN 仍然是上手最快的方式。
行级过滤和列级遮蔽经常同时出现。比如一个区域经理只能查看自己区域的订单，同时订单金额还要根据是否超过审批权限做遮蔽。视图里可以先在 WHERE 中限定区域，再在 SELECT 的 CASE WHEN 中判断金额返回原文还是部分隐藏。两个动作都在同一条 SQL 的解析阶段生效，应用层拿到的结果就是最终应该展示的内容，大大减少了前端二次处理的压力。
四、动态遮蔽与真正加密的边界
很多开发者会把视图里的 CASE WHEN 遮蔽当成加密，这是一个需要纠正的概念。动态遮蔽的数据在磁盘上仍然是明文，视图只是在返回结果前做了一层替换。真正能够防止拖库的是静态加密，比如 SQL Server 的 Always Encrypted、MySQL 的 Enterprise TDE 或者应用层的 AES 加密。静态加密在落盘前已经把明文变成密文，即使备份文件泄露也无法直接读取。而视图遮蔽的价值在于防止权限不足的内部人员通过合法查询渠道看到完整数据，两者目标不同。
视图遮蔽还有一个天然弱点，就是如果用户能够绕过视图直接访问基础表，遮蔽规则就完全失效。因此权限回收是整套方案里的硬性要求。以 SQL Server 为例，可以只给业务账号授予视图的 SELECT 权限，不授予 employees 和 orders 的任何权限。同时要定期审计权限继承关系，避免某个数据库角色把底表权限间接分发了出去。另一个常见问题是视图里的函数稳定性，比如 SQL Server 的 USER_NAME() 在视图定义中每次执行结果可能受上下文影响，如果视图被缓存或者用于索引视图，可能带来意想不到的权限判断误差。所以这类动态视图通常不建议创建索引，避免函数结果被物化后无法反映当前用户。
不同数据库对视图内函数的使用限制也不一样。MySQL 的视图定义中可以使用 CURRENT_USER()，但不能使用某些会改变状态的函数。PostgreSQL 的视图默认是安全屏障视图时，需要注意 leakproof 函数的使用，否则优化器可能把视图条件下推，导致函数执行顺序变化。实际落地时，可以先在测试环境模拟多个登录用户反复查询，确认遮蔽结果和行过滤结果都符合预期。对于性能敏感的系统，建议为视图依赖的底层表建立合适的索引，特别是 WHERE 过滤条件中的租户 ID、区域 ID 等字段，否则视图查询可能因为全表扫描而变慢。
最后要强调的是，行级安全不是一个单一的 SQL 技巧，而是视图封装、CASE WHEN 条件判断、用户上下文读取和权限回收共同组成的一套机制。把 CASE WHEN 只当成数据脱敏工具，往往会忽略行级过滤的价值。把行级过滤只理解成加一个 WHERE，又会漏掉列级遮蔽的灵活性。两者结合，才能在不引入复杂第三方组件的前提下，用轻量级的数据库原生能力构建起一层可靠的数据访问屏障。