数据脱敏并不一定要依赖独立网关或改表结构。SQL视图本身就是一条预定义的查询语句，当视图定义里包含掩码函数、条件判断或动态用户判断时，查询方拿到的结果就已经是脱敏后的数据。这种方式将脱敏逻辑固定在数据库入口处，对上层应用透明，尤其适合报表、BI工具、临时分析账号等场景。
一、视图脱敏的运行机制
视图是一种数据库对象，它保存的不是数据，而是一条查询语句。执行 CREATE VIEW 时，数据库通常只记录视图定义的文本；当用户查询视图时，优化器会把视图展开或者直接按视图定义执行查询。因此可以在视图里对敏感列做包装，让结果集天然变成脱敏数据。
例如一个员工表存放了真实手机号，业务方只需要联系前三位和后四位。此时可以创建视图，将 mobile 列替换为 CONCAT 拼接的掩码字符串。下游查询 v_employee_safe 时，接触不到真实手机号。相比直接修改原表，视图的优势在于脱敏逻辑集中管理，后续调整掩码规则，只需替换视图定义，不用改动表结构，也不影响写入程序。
但要注意，视图脱敏只作用于通过视图发起的查询。如果原表 SELECT 权限仍然开放，用户完全可以绕过视图。因此视图脱敏必须配合权限回收，把原表查询权限收回到最小范围，只授予视图查询权限。
-- 创建员工表
CREATE TABLE employee (
emp_id INT PRIMARY KEY,
emp_name VARCHAR(50),
mobile VARCHAR(20),
id_card VARCHAR(18),
salary DECIMAL(10,2)
);
-- 创建脱敏视图
CREATE VIEW v_employee_safe AS
SELECT
emp_id,
emp_name,
CONCAT(LEFT(mobile, 3), '****', RIGHT(mobile, 4)) AS mobile_masked,
CONCAT(LEFT(id_card, 6), '********', RIGHT(id_card, 4)) AS id_card_masked,
CASE
WHEN salary >= 10000 THEN CONCAT(LEFT(salary, 2), '****')
ELSE '****'
END AS salary_level
FROM employee;
二、动态替换典型场景与SQL实现
动态替换不是简单把列固定改成星号，而是根据连接用户、终端来源、访问时间段等条件，返回不同粒度的数据。比如HR主管可以查看到完整薪资，普通查询账号只能看到薪资等级或空值。视图可以读取当前用户信息，配合 CASE WHEN 实现这一逻辑。
以 MySQL 为例，可以用 SUBSTRING_INDEX(USER(),'@',1) 获取当前连接用户名。下面视图定义中，只有当用户为 hr_director 时才返回薪资原值，其余用户返回空或掩码。也可以使用 CURRENT_USER 或 SESSION_USER，但要注意它们的值来自账号解析，不同数据库存在差异。
-- 动态替换薪资字段，根据当前数据库用户返回不同结果
CREATE VIEW v_payroll_dynamic AS
SELECT
emp_id,
emp_name,
mobile,
CASE
WHEN SUBSTRING_INDEX(USER(), '@', 1) = 'hr_director' THEN salary
WHEN SUBSTRING_INDEX(USER(), '@', 1) = 'team_leader' THEN salary * 0.8
ELSE NULL
END AS dynamic_salary
FROM payroll;
这个视图在查询时动态计算，即使 payroll 表数据没变，不同账号看到的 dynamic_salary 也会不同。这比复制几份脱敏表更灵活。缺点是视图定义包含业务规则，用户切换逻辑需要维护 CASE WHEN；如果角色很多，建议配合用户属性表或函数。
针对字符串字段，同样可以使用 CASE WHEN 动态替换手机号。下面的例子中，只有管理员和支持主管能看到完整号码，其他账号只能看到中间四位被星号遮挡的版本。
-- 使用 CASE WHEN 动态替换手机号
CREATE VIEW v_contact_dynamic AS
SELECT
user_id,
CASE
WHEN SUBSTRING_INDEX(USER(), '@', 1) IN ('admin', 'support_lead') THEN phone
ELSE CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4))
END AS phone_view
FROM user_contact;
三、权限配置与防绕过
视图脱敏最常见的错误是只创建视图却不回收原表权限。只要某个账号仍具备 employee 表的 SELECT 权限，它就可以绕开 v_employee_safe，直接查询真实 mobile、id_card。因此在创建视图后，必须立即执行最小权限调整：回收原表 SELECT，只保留视图 SELECT。
-- MySQL 最小权限示例 REVOKE SELECT ON company.employee FROM 'report_user'@'%'; GRANT SELECT ON company.v_employee_safe TO 'report_user'@'%'; FLUSH PRIVILEGES;
如果不同账号需要不同脱敏粒度，可以为不同角色创建不同视图，或者在一个视图中用 CASE WHEN 区分。前一种权限更清晰，后一种维护成本低但定义更复杂。生产环境建议把角色与权限绑定，避免把用户账号硬编码进视图定义。可以在数据库里建立用户属性表，视图里关联该表判断脱敏级别。例如用户属性表记录 user_name 和 mask_level，视图 JOIN 该表后决定保留几位号码。这样账号权限和脱敏规则解耦。
-- 通过掩码级别表实现动态脱敏
CREATE TABLE user_mask_level (
user_name VARCHAR(60) PRIMARY KEY,
mask_level TINYINT NOT NULL
);
CREATE VIEW v_employee_rule AS
SELECT
e.emp_id,
e.emp_name,
CASE u.mask_level
WHEN 0 THEN e.mobile
WHEN 1 THEN CONCAT(LEFT(e.mobile, 3), '****', RIGHT(e.mobile, 4))
WHEN 2 THEN CONCAT(LEFT(e.mobile, 2), '******', RIGHT(e.mobile, 4))
ELSE NULL
END AS mobile_view,
CASE u.mask_level
WHEN 0 THEN e.salary
ELSE NULL
END AS salary_view
FROM employee e
LEFT JOIN user_mask_level u
ON u.user_name = SUBSTRING_INDEX(USER(), '@', 1);
四、性能影响与替代方案
普通视图不是物化结果，它只是把定义语句合并到外层查询中。如果视图里对字段做了 LEFT、CONCAT、REGEXP_REPLACE 等函数处理，这些函数会在查询执行阶段对每一行计算一次。当结果集很大时，CPU 消耗会明显增加。更关键的是，如果查询以脱敏后的值作为过滤条件，比如 WHERE mobile_view = '138****1234'，优化器通常无法使用原始 mobile 列上的索引，因为列已经在函数里被包了一层。此时会退化为全表扫描。
优化方式首先是把脱敏列与索引列分开。业务查询如果需要按手机号精确匹配，应当基于真实列建立索引，并通过后台服务在写入或查询前加密匹配，而不是依赖脱敏视图做筛选。对于仅输出展示的脱敏场景，数据量不大时函数开销可以接受；如果报表必须对百万级数据反复导出，建议采用定时物化表或数据库原生动态数据脱敏功能。
SQL Server 提供 Dynamic Data Masking，Oracle 有 Data Redaction，PostgreSQL 可以通过 RLS 策略和视图结合。它们比纯视图更容易在查询阶段决定脱敏行为，而且不要求在每一列上手动写 CASE WHEN。缺点是语法和实现与数据库强绑定，迁移时要重写规则。视图方式则最通用，几乎所有关系型数据库都支持，适合跨数据库或快速验证。
通过 SQL 视图实现数据脱敏，核心不是简单地用星号替换字符串，而是把做权限判断和字段处理统一放到数据库查询入口。创建视图后必须同时回收原表权限，并根据实际连接用户来动态决定返回明文还是掩码。这样才能在业务快速接入的同时，把敏感字段暴露面控制住。