视图脱敏需显式重命名字段、禁用select *、预处理null值、避免哈希用于展示、where过滤应下推或改用生成列索引，兼顾安全与性能。
用视图隐藏敏感字段时，SELECT * 会暴露原始列名
视图本身不改变底层表结构，SELECT * 查询视图仍会返回定义时的列名——如果原表有 id_card、phone，而视图里写的是 CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) AS phone，那列名还是 phone，前端或下游系统可能误以为这是明文。
实操建议：
- 视图中所有脱敏字段必须显式重命名，比如
CONCAT(...) AS phone_masked - 禁止在视图定义中使用
SELECT *，必须逐个列出字段并控制别名 - 配合数据库权限：收回对基表的
SELECT权限，只开放视图查询权
MySQL 中 CONCAT + SUBSTRING 脱敏在 NULL 值下返回 NULL
当 phone 字段为 NULL，CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) 整个表达式结果是 NULL，不是空字符串或占位符，容易导致业务侧空指针或展示异常。
实操建议：
- 用
IFNULL(phone, '')或COALESCE(phone, '')预处理空值 - 更稳妥写法：
CONCAT(LEFT(IFNULL(phone, ''), 3), '****', RIGHT(IFNULL(phone, ''), 4)) AS phone_masked - 注意
LEFT('', 3)返回空串，不会报错，但要确认业务是否接受空脱敏结果
PostgreSQL 的 pgcrypto 扩展做哈希脱敏不适合前端展示比对
有人用 digest(phone, 'sha256') 把手机号转哈希值，以为“不可逆=安全”，但实际场景中，若前端需要按脱敏后值筛选（比如查“138****1234”的用户），哈希值完全无法匹配原始模式，也丧失可读性。
实操建议：
- 哈希仅适用于去标识化（如用户行为归因）、不适用于展示型脱敏
- 展示用固定格式掩码（如
overlay(phone placing '****' from 4 for 4)） - 若真要哈希，记得加盐：
hmac(phone, 'my_salt_key', 'sha256')，否则彩虹表可批量反推
WHERE 条件里对脱敏字段过滤会导致全表扫描
比如视图里定义了 CONCAT(...) AS phone_masked，然后外部查询写 WHERE phone_masked = '138****1234'，数据库无法利用原表 phone 索引，因为脱敏逻辑是运行时计算的。
实操建议：
- 需要条件过滤的字段，不要在视图里脱敏；改用应用层或带参数的物化视图（如 PostgreSQL 的
MATERIALIZED VIEW+ 定期刷新） - 若必须在 SQL 层过滤，把脱敏逻辑下推到
WHERE子句中，例如直接写WHERE phone LIKE '138%1234'，再在SELECT里脱敏输出 - MySQL 8.0+ 可考虑生成列 + 索引：
ALTER TABLE user ADD phone_masked VARCHAR(11) STORED AS (CONCAT(...))，然后对生成列建索引
字段脱敏不是加个函数就完事，关键是看数据流向：谁读、怎么读、要不要筛、会不会空、有没有索引依赖。漏掉任意一环，要么泄露，要么慢得没法用。
