手机号中间四位打成星号后，两份报表按号码 join 全部为空，运营没法把投诉单和订单对上。乍看像缓存或者权限的锅，追下去往往不是。
SELECT md5(concat('salt', user_id)) AS uid, mask(phone)
FROM users;
追下去是这么回事：掩码是有损的，138****8000 这种值在两张表里能撞出几千条，无法做等值关联。脱敏前没有留一个不可逆的代理键。
碰到「脱敏数据关联分析」这类问题，我习惯先把当前配置原样备份一份，改坏了立刻换回来，不用现场推。一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。
先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。别只看报错的最后一行，往上看几行，真正的起因通常在上面。
具体做法是，关联改用用户 ID 或哈希值 不用掩码后的号码；需要展示时按权限还原后四位；同一用户保持稳定哈希 加固定盐；报表层建映射表 只对授权角色开放。
验收就看一点，两份报表按 uid 能完整对上 行数与原始数据一致。