数据脱敏这事儿，看似简单，里头门道不少。很多人第一反应是直接改数据库，或者写个视图、触发器来自动处理。但说实话，这些做法都不太靠谱——容易漏场景、难调试，搞不好还影响索引下推。那么，哪种方法最稳妥？先说个结论：在查询时动手脚，不改原始数据，才是最安全、最常用的做法。
MySQL中用CONCAT和SUBSTRING做简单掩码最稳妥
直接在查询时脱敏，不改原始数据，是最安全、最常用的做法。别动表结构，也别写触发器或视图来“自动”处理——那些做法容易漏场景、难调试、还可能影响索引下推。
手机号常见掩码格式是138****1234，身份证是110101****1234567X。用CONCAT拼接前后段，SUBSTRING截取中间部分即可：
SELECT CONCAT(SUBSTRING(phone, 1, 3), '****', SUBSTRING(phone, -4)) AS masked_phone, CONCAT(SUBSTRING(id_card, 1, 6), '****', SUBSTRING(id_card, -4)) AS masked_id_cardFROM users;
注意：SUBSTRING(phone, -4)在MySQL 5.5+才支持负数起始位置；若用老版本，得写成SUBSTRING(phone, LENGTH(phone)-3)。
SUBSTRING第三个参数省略时默认取到末尾，但SUBSTRING(str, -n)更简洁，不过得先确认MySQL版本。- 手机号长度不固定（如带国际区号或含空格），先用
TRIM和REPLACE清洗再截取。 - 身份证最后一位可能是
X，SUBSTRING(id_card, -4)能正确保留它，别用RIGHT替代——RIGHT对X没毛病，但语义不如SUBSTRING清晰。
用REGEXP_REPLACE批量替换更灵活（MySQL 8.0+）
如果字段里混着各种格式（如138-1234-5678、+86 13812345678），正则替换比手动截取更可靠。
手机号掩码示例：
SELECT REGEXP_REPLACE(phone, '^(d{3})d{4}(d{4})$', '1****2') AS masked_phone FROM users;身份证掩码（18位）：
SELECT REGEXP_REPLACE(id_card, '^(d{6})d{8}(d{4})$', '1****2') AS masked_id_card FROM users;- 必须确保正则能准确匹配——比如身份证要限定18位，否则可能误伤15位旧码或错误数据。
REGEXP_REPLACE性能比字符串函数略低，大数据量分页查询时要留意执行计划是否还能走索引。- MySQL 5.7不支持该函数，强行升级前得先评估兼容性，别只看文档说“支持”，要实测你的字符集（尤其是utf8mb4）下是否正常捕获。
应用层掩码比数据库层更可控
把脱敏逻辑提到代码里（如Ja va的String.substring、Python的切片），好处很明显：规则可配置、可灰度、可审计、还能结合业务上下文（比如只对非管理员角色返回掩码值）。
- 数据库层掩码一旦写死SQL，改规则就得发版或改查询，线上紧急调整很被动。
- 某些ORM框架（如MyBatis）支持
@SelectProvider动态拼SQL，但不如在Service层统一处理干净。 - 别在DAO层返回明文再靠前端JS掩码——HTTPS能防传输窃听，但数据库日志、慢查日志、监控平台快照都可能泄露原始值。
千万别用UPDATE直接覆盖原始字段
曾经有团队为“省事”把手机号全更新成138****1234存进表里，结果导出报表时发现没法反查、没法校验、连模糊搜索（如查“138123”开头）都失效了。原始数据丢失后不可逆，备份恢复也救不回来。索引字段被改成固定字符串后，等值查询变全表扫描，QPS掉一半不止。更严重的是，合规审计时要求“原始数据可追溯”，你拿不出明文，就是重大过失。
真正需要存储脱敏值的场景极少（比如导出给第三方做统计且明确约定不回溯），此时应新增masked_phone字段，原字段保持不变，并加注释说明用途。这才是真正稳妥的脱敏之道。
