最稳妥的mysql脱敏方式是查询时用concat和substring做掩码，不改原始数据；手机号掩码为1381234，身份证为1101011234567x，需注意mysql版本兼容性及数据清洗。
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_card FROM 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）下是否正常捕获
应用层掩码比数据库层更可控
把脱敏逻辑提到代码里（如Java的String.substring、Python的切片），好处很明显：规则可配置、可灰度、可审计、还能结合业务上下文（比如只对非管理员角色返回掩码值）。
- 数据库层掩码一旦写死SQL，改规则就得发版或改查询，线上紧急调整很被动
- 某些ORM框架（如MyBatis）支持
@SelectProvider动态拼SQL，但不如在Service层统一处理干净 - 别在DAO层返回明文再靠前端JS掩码——HTTPS能防传输窃听，但数据库日志、慢查日志、监控平台快照都可能泄露原始值
千万别用UPDATE直接覆盖原始字段
曾经有团队为“省事”把手机号全更新成138****1234存进表里，结果导出报表时发现没法反查、没法校验、连模糊搜索（如查“138123”开头）都失效了。
- 原始数据丢失不可逆，备份恢复也救不回来
- 索引字段被改成固定字符串后，等值查询变全表扫描，QPS掉一半不止
- 合规审计时要求“原始数据可追溯”，你拿不出明文，就是重大过失
真正需要存储脱敏值的场景极少（比如导出给第三方做统计且明确约定不回溯），此时应新增masked_phone字段，原字段保持不变，并加注释说明用途。
