MySQL不支持查询时自动脱敏，但可在BEFORE INSERT触发器中预处理模糊化敏感字段（如手机号、身份证号），仅适用于无需原始值的日志表等场景；需用确定性字符串函数、加长度校验、避免非确定性逻辑，并注意NULL和字符集问题。
MySQL 本身不支持“查询时自动脱敏”，但可以在 BEFORE INSERT 触发器中对敏感字段做**预处理式模糊化**——即写入前就改成掩码格式（如 138****1234），后续查出来就是脱敏态。这适合日志表、报表宽表等**不需要原始值**的场景；若需保留明文供合规审计或解密使用，此法不可逆，别用。
BEFORE INSERT 触发器里怎么安全地模糊手机号
核心是用字符串函数截取+拼接，避免调用非确定性函数（如 RAND()）或触发 MySQL 报错 View's SELECT contains a non-deterministic function（虽然这是视图报错，但同理，触发器里也禁用不确定逻辑）。
- 正确写法：
SET NEW.phone = CONCAT(LEFT(NEW.phone, 3), '****', RIGHT(NEW.phone, 4)); - 必须加长度判断，否则空值或短于 7 位会出错：
IF LENGTH(NEW.phone) >= 11 THEN ... END IF; - 别用
REPLACE(NEW.phone, SUBSTRING(NEW.phone, 4, 4), '****')—— 容易误替换中间重复数字，且性能差 - 注意字符集：如果字段是
utf8mb4，LEFT()和RIGHT()按字节算，但手机号纯数字无影响
身份证号模糊化要避开的坑
身份证号长度固定（18 位），但末尾可能是字母 X，RIGHT(NEW.id_card, 1) 必须保留它；同时不能简单截中间 8 位，因为第 7–14 位是出生日期，属于强敏感段，必须掩掉。
- 推荐写法：
SET NEW.id_card = CONCAT(LEFT(NEW.id_card, 6), '********', RIGHT(NEW.id_card, 1)); - 错误示范：
SUBSTRING(NEW.id_card, 1, 6) + '********' + SUBSTRING(NEW.id_card, -1)——+在 MySQL 中是数值加法，非字符串拼接，会导致转成 0 - 务必检查字段是否允许 NULL：
IF NEW.id_card IS NOT NULL AND LENGTH(NEW.id_card) = 18 THEN ... - 别在触发器里调用自定义函数（如
mask_idcard()）却不声明DETERMINISTIC，主从复制可能中断
为什么不能在触发器里做“加密+Base64”再存
能做，但代价高、风险大，多数业务没必要。AES 加密返回的是 VARBINARY，存进 VARCHAR 前得 TO_BASE64()，而 TO_BASE64() 是 MySQL 5.7.28+ 才支持的函数，低版本直接报错。
-
AES_ENCRYPT()密钥若硬编码在触发器里，轮换密钥就得重装触发器，运维成本爆炸 - 加密后 Base64 字符串长度约是原文 1.3 倍，18 位身份证加密后 Base64 超过 40 字符，字段长度没留够就截断
- 触发器执行期间锁行，加解密耗 CPU，高并发插入时容易成为瓶颈
- 真正需要加密的场景（如用户主表），应该由应用层完成，数据库只负责存储密文——触发器不是加密的合理位置
模糊化后还能模糊查询吗
不能直接 LIKE '%1234' 查脱敏值，因为 138****1234 的后 4 位虽保留，但前缀已失真。若业务真有“按手机号后缀查用户”需求，必须额外建一个 phone_suffix 字段，在同一触发器里同步提取并存入：
SET NEW.phone_suffix = RIGHT(NEW.phone, 4); SET NEW.phone = CONCAT(LEFT(NEW.phone, 3), '****', RIGHT(NEW.phone, 4));
然后查：SELECT * FROM users WHERE phone_suffix = '1234';。这个额外字段要加索引，否则查得慢。别指望在脱敏字段上建函数索引（MySQL 不支持函数索引），也别用 WHERE phone LIKE '%1234' —— 全表扫，还查不到。
最易被忽略的一点：触发器只管写入，不管更新。如果某条记录的 phone 字段后来被 UPDATE 修改，旧的模糊值不会自动刷新。要么补一个 BEFORE UPDATE 触发器，要么接受“历史数据脱敏态不一致”的现实——后者在日志类场景里其实可接受。
