直接用MD5()更新字段会导致兼容性问题（SQLite/SQL Server/Oracle不支持）、类型不匹配（32位哈希值≠手机号格式）、安全性不足（MD5非加密且易碰撞）；推荐用字符串掩码如138**5678，兼顾可读性、兼容性与安全性。
SQL里直接用MD5()更新字段会遇到什么问题
mysql 8.0+ 和 postgresql 支持原生 md5()，但 sqlite、sql server、oracle 都不认这个函数名；更麻烦的是，哪怕能跑通，md5('13812345678') 返回的是 32 位十六进制字符串，和原始手机号长度、格式完全不兼容——下游系统可能直接报类型错或校验失败。
- MySQL 中
MD5()返回VARCHAR(32)，不能当手机号用 - PostgreSQL 需显式写
md5(phone::text)，否则报“函数不存在” - SQL Server 得用
HASHBYTES('MD5', phone)，返回VARBINARY，还得转成十六进制字符串（CONVERT(VARCHAR, HASHBYTES('MD5', phone), 2)） - 脱敏不是加密：MD5 不可逆但也不安全，别拿它当生产环境的隐私保护方案
用掩码函数做可读性脱敏更靠谱
真正实用的脱敏是“看得出类型、看不出真实值”，比如手机号变成 138****5678，邮箱变成 u***@example.com。这类操作不依赖哈希，靠字符串截取+拼接，兼容性好、执行快、结果可控。
- MySQL：用
CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) - PostgreSQL：用
left(phone, 3) || '****' || right(phone, 4) - SQL Server：用
STUFF(phone, 4, 7, '****')（从第4位开始删7位，替换成****） - 注意空值：
WHERE phone IS NOT NULL AND phone != ''必须加上，否则LEFT(NULL, 3)返回 NULL，整条记录被静默跳过
在SQL面板中安全执行脱敏更新的实操要点
很多 BI 工具或数据库管理界面（如 DBeaver、Navicat、Superset SQL Lab）的 SQL 面板默认开启自动提交，一按回车就永久改库——没备份、没 WHERE 条件、没预览，等于直接爆破生产表。
- 先查后改：
SELECT id, phone, CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) AS masked FROM users LIMIT 5;看效果再动手 - 加范围限制：
UPDATE users SET phone = CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) WHERE id BETWEEN 1000 AND 1010;别裸写WHERE 1 - 开事务兜底：
BEGIN; UPDATE ...; SELECT COUNT(*) FROM users WHERE phone LIKE '138****%'; ROLLBACK;确认无误再COMMIT - 别在
WHERE里用函数过滤脱敏字段：WHERE MD5(phone) = 'xxx'会导致全表扫描，索引失效
测试时最容易漏掉的边界情况
真实数据永远比样例脏：空格、括号、分机号、国际前缀、NULL、超长字符串……随便一个都可能让掩码逻辑崩掉，而 SQL 面板通常只报“ERROR 1292: Truncated incorrect value”，不告诉你哪一行炸了。
- 清理干扰字符：
TRIM(REPLACE(REPLACE(phone, '-', ''), ' ', ''))再脱敏 - 校验长度：
WHERE LENGTH(TRIM(phone)) = 11过滤掉座机或错误格式 - 邮箱脱敏要分段：
SUBSTRING_INDEX(email, '@', 1)取用户名，SUBSTRING_INDEX(email, '@', -1)取域名，分别掩码 - 测试完立刻查
SELECT COUNT(*) FROM users WHERE phone REGEXP '^[0-9]{3}\*{4}[0-9]{4}$' = 0;确保每条都命中规则
