脱敏必须用视图封装，禁用应用层脱敏和非确定性表达式；触发器仅用于写入清洗且不可逆；须严格隔离原表权限，确保视图是唯一查询出口。
脱敏字段必须用视图封装，不能直接查原表
视图是脱敏落地的最小可行单元。直接在应用层做脱敏容易漏字段、绕过逻辑，也难统一维护；而用 UPDATE 或 SELECT 里写 CONCAT('***', SUBSTRING(phone, -4)) 这类表达式，一来可读性差，二来没法复用，三来权限控制粒度太粗（只能到表级）。视图能隐藏真实列、强制走脱敏逻辑，且支持按角色定义不同视图（比如客服视图显示后4位，审计视图完全屏蔽）。
实操建议：
- 为每类敏感字段（
id_card、phone、email）单独建视图，不要堆在一个大视图里——改一个字段逻辑不影响其他 - 视图中所有脱敏函数必须用确定性表达式，避免
NOW()、RAND()等非确定函数，否则可能触发 MySQL 的CREATE VIEW报错View's SELECT contains a non-deterministic function - 给视图加注释说明脱敏规则，例如：
COMMENT '手机号显示前3后4，中间掩码为****'，后续交接或排查时省力
触发器只用于写入时自动清洗，不用于查询脱敏
触发器不是脱敏的主力，它的定位很窄：在数据插入/更新瞬间，把明文敏感字段转成脱敏值存进表里。比如用户注册时传入完整手机号，BEFORE INSERT 触发器把它截断再存。但注意——这和“查询时动态脱敏”是两回事。一旦用了触发器清洗，就等于放弃了原始数据，不可逆。
常见错误现象：
- 在
AFTER SELECT上试图挂触发器——MySQL 不支持SELECT触发器，会直接报错ERROR 1419: You do not have the SUPER privilege... - 用
BEFORE UPDATE把已脱敏字段又“二次脱敏”，比如对***1234再执行一次掩码，结果变成****34 - 触发器里调用存储函数处理身份证号，但没声明
DETERMINISTIC，导致主从复制失败或无法创建
正确做法是：仅对明确不需要原始值的场景（如日志表、统计宽表）用触发器预清洗；核心业务表仍保留明文，靠视图控制查询出口。
视图 + 触发器组合的关键约束：权限必须分层隔离
视图本身不解决权限问题。如果用户有原表 SELECT 权限，他就能绕过视图直接查明文。所以必须切断原表访问路径。
实操要点：
- 收回所有业务账号对敏感表的
SELECT权限，只授予对应视图的SELECT - 用
DEFINER方式创建视图（如DEFINER = 'admin'@'%'），确保即使普通用户无原表权限，也能通过视图查到脱敏后数据 - 禁止给应用账号
SHOW VIEW权限——否则它能SHOW CREATE VIEW看到视图定义，反推出脱敏逻辑甚至原表结构 - 测试时用实际业务账号登录，执行
SELECT * FROM user_info（原表）应报ERROR 1142: SELECT command denied to user，而查user_info_masked视图才成功
性能与兼容性：视图字段别名和索引失效要提前踩坑
MySQL 视图是“虚拟表”，底层仍是全表扫描。如果脱敏字段上原本有索引（比如 phone 字段建了唯一索引），视图里用 SUBSTRING(phone, 1, 3) 就无法命中索引，查询会变慢。
影响明显的几个点：
- 视图中所有计算字段（包括脱敏表达式）都不能被索引覆盖，
EXPLAIN会显示type: ALL - 如果业务依赖模糊搜索（如查“张*”姓用户），视图里用
LEFT(name, 1)拼接，就无法利用name索引，得靠全文索引或前置生成拼音字段 - 跨版本迁移要注意：MySQL 5.7 对视图的
ALGORITHM = MERGE支持更稳；8.0+ 虽支持TEMPTABLE，但复杂脱敏表达式可能导致临时表膨胀 - ORM 框架（如 MyBatis、SQLAlchemy）默认把视图当表用，但有些会尝试
DESCRIBE原表结构——这时要确保视图字段名和类型与原表兼容，否则映射报错
最常被忽略的是：开发本地连的是测试库，视图权限没配全，查出来是空或报错；上线后才发现生产环境权限策略更严，而视图定义里又硬编码了库名，导致跨库查询失败。这类问题得在部署前用最小权限账号跑通全流程。
