如何利用SQL视图在保持基表结构不变的前提下实现数据脱敏

视图本身不脱敏，真正有效的是“显式字段处理+权限隔离”组合；必须手动编写覆盖NULL、空值及长度异常的CASE WHEN脱敏表达式，并严格回收基表SELECT权限、仅授予视图权限，否则用户可绕过视图直接查出明文。

视图本身不脱敏，只封装查询逻辑；真正起作用的是“显式字段处理 + 权限隔离”组合。单独建视图但不收基表权限，等于没做任何脱敏。

视图里必须手动写脱敏表达式，不能靠别名或注释

很多人以为把 phone 改名叫 phone_masked 就算脱敏了，其实只是换了个名字，值还是明文。MySQL、PostgreSQL 都没有 MASKED WITH 这种语法，SQL Server 的该语法也仅限于 CREATE TABLE 或 ALTER TABLE，根本不能用在视图里。

• CASE WHEN phone IS NOT NULL THEN CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) ELSE '***' END AS phone_masked 是可行写法，但必须覆盖 NULL、空字符串、长度异常三种情况
• 别用 CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) 直接写——phone 为 NULL 时整个结果是 NULL，前端容易崩
• PostgreSQL 要注意 '' 和 NULL 区分，得分开判：WHEN phone IS NOT NULL AND phone != ''
• JSON 字段如 meta 必须先提取再脱敏：meta->>'phone'（PostgreSQL）或 TRIM(BOTH '"' FROM JSON_EXTRACT(meta, '$.phone'))（MySQL），否则返回带引号字符串或 NULL

权限隔离比脱敏逻辑更重要

用户只要还有 SELECT 权限在基表上，就能绕过视图直接查出明文。视图不是防火墙，它只是个查询模板。

• 必须显式执行：REVOKE SELECT ON db_name.users FROM 'user_a'@'%'
• 只授视图权限：GRANT SELECT ON db_name.v_user_safe TO 'user_a'@'%'
• 检查是否误授宽泛权限：SHOW GRANTS FOR 'user_a'@'%'，重点看有没有 SELECT ON db_name.*
• MySQL 8.0+ 可用角色打包权限，避免漏授；PostgreSQL 需确认 SET ROLE 是否激活

WHERE 条件不能依赖脱敏后字段

视图里的 phone_masked 是计算列，数据库优化器无法对其建立索引，WHERE 中使用它会导致全表扫描。

• WHERE phone_masked = '138****1234' 查不到数据，也不走索引
• 真要按格式过滤，得回到原始字段：WHERE phone LIKE '138%1234' 或加冗余前缀字段（如 phone_prefix CHAR(3)）
• BI 工具常自动把筛选拖到视图字段上，需提前禁用该字段的过滤能力
• 脱敏列不可用于 JOIN 或 GROUP BY，否则结果不可控

最容易被忽略的是：视图定义里用了 SELECT * 或漏写了某个敏感字段，就会让脱敏形同虚设；更隐蔽的是 DEFINDER 权限缺失——如果创建视图的账号本身没权限读某列，那连视图都查不出来，报错却看不出原因。