SQL数据脱敏需兼顾安全与业务可用，核心是按权限控制数据可见性；查询层脱敏灵活但有性能开销，存储层脱敏安全高效但灵活性低；应据是否允许明文、查询需求及改造能力选择方案，生产环境推荐混合使用。
SQL数据脱敏不是简单地把字段值替换成星号，而是要在保障业务可用的前提下，防止敏感信息泄露。核心思路是：该看到的人看到真实数据，不该看的人看到脱敏后数据。实现位置不同，效果、性能和维护成本差异很大——查询层脱敏灵活但有性能开销，存储层脱敏安全高效但改动大、灵活性低。
查询层脱敏：动态拦截，按需处理
在SQL执行前或结果返回前，由中间件、数据库代理（如ShardingSphere、MyBatis插件）或数据库自身的函数/视图机制，对SELECT语句中的敏感字段做实时替换。不修改原始数据，只改变查询输出。
- 适用场景：多租户系统、开发测试环境、权限粒度细（如HR能看到完整身份证，普通员工只能看后4位）
-
常见做法：
- 用数据库内置函数脱敏：MySQL中
CONCAT(LEFT(id_card, 3), '****', RIGHT(id_card, 4)) - 定义视图隐藏原始字段：
CREATE VIEW emp_safe AS SELECT name, CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) AS phone FROM employee; - 在ORM层（如MyBatis）用TypeHandler或ResultMap拦截字段值，注入脱敏逻辑
- 用数据库内置函数脱敏：MySQL中
-
注意点：WHERE条件中若含脱敏字段（如
WHERE phone = '138****1234'），可能查不到数据——脱敏仅作用于输出，不改变索引和查询逻辑，需配合“双字段”策略（存明文+脱敏值）或使用可搜索加密
存储层脱敏：源头加密，一劳永逸
在数据写入数据库时就完成脱敏或加密，落盘即为不可逆变形（如哈希、AES加密、格式保留加密FPE），后续所有读取都基于脱敏后数据。原始明文不落地。
- 适用场景：合规强要求（如GDPR、等保三级）、审计日志、备份数据、离线分析库
-
常见做法：
- 应用层脱敏后再INSERT：手机号入库前调用
maskPhone("13812345678") → "138****5678" - 数据库触发器自动脱敏：
BEFORE INSERT ON user FOR EACH ROW SET NEW.id_card = CONCAT(LEFT(NEW.id_card, 6), '******', RIGHT(NEW.id_card, 4)); - 使用TDE（透明数据加密）或列级加密（如MySQL 5.7+的
AES_ENCRYPT()）存储密文，解密需密钥授权
- 应用层脱敏后再INSERT：手机号入库前调用
- 注意点：脱敏后字段通常无法用于精确匹配、排序、模糊查询；若需检索，应额外保存脱敏标识（如身份证哈希值）或采用FPE保持格式与可计算性
怎么选？关键看三个问题
不用纠结“哪个更好”，而要看你的实际约束：
- 是否允许原始数据存在？不允许→必须存储层；允许且需灵活控制→查询层更合适
- 有没有高频模糊/范围查询需求？有→查询层（保留明文索引）；无→存储层更省心
- 能否改造应用或DBA权限是否受限？不能改应用/无DBA权限→倾向查询层（如加代理）；能控全链路→存储层更彻底
混合方案：兼顾安全与实用
生产环境中，单一方式往往不够。推荐组合使用：
- 核心敏感字段（如身份证、银行卡号）在存储层做不可逆脱敏+索引字段分离（如存SHA256哈希用于校验）
- 非核心但需展示的字段（如手机号、邮箱）在查询层按角色动态脱敏，支持开发/测试/运维不同策略
- 所有脱敏规则统一配置化管理（如YAML定义字段+规则+生效环境），避免硬编码
脱敏不是加一层马甲，而是构建数据访问的信任边界。查得准、改得稳、管得住，才是落地的关键。
