英国GDPR将至：如何捕获现有SELECT语句并分配代理键/伪值（无需重写存储过程）

嘿，这个场景我太熟了——GDPR要生效，一堆老存储过程里的不规范SELECT语句，改起来简直要命。不用慌，咱们从数据库底层下手，用透明拦截的思路解决，完全不用碰现有代码：

核心思路：在查询执行链路中间做“隐形改写” #

不用动存储过程的关键，就是让所有SELECT语句在到达数据库执行引擎前，先经过一层自动改写——替换敏感字段为代理键，同时完成伪匿名化，最后返回和原查询完全一致结构的结果，原脚本根本感知不到变化。

1. 先做准备工作：梳理敏感映射 #

首先得把所有15个数据库里的敏感信息摸清楚：

• 列出来需要替换代理键的字段（比如用户ID、订单ID这类关联键），给每个字段建一张代理键映射表，存真实值和不可逆的代理值（比如用哈希算法生成代理ID，别用自增ID，防止反推）；
• 标记需要伪匿名化的字段（姓名、手机号、邮箱），提前写好对应的匿名化函数（比如姓名只留首字加星号，手机号隐藏中间四位）。

2. 数据库原生拦截方案（以SQL Server/PostgreSQL为例） #

不同数据库有不同的原生工具，挑两个常用的给你说：

• SQL Server：用扩展事件（Extended Events）捕获所有SELECT语句，配合CLR自定义程序集做SQL解析和改写。或者更简单的，用会话级别的触发器，在用户登录时设置上下文，然后用自定义函数自动替换查询中的敏感字段。重点是要保证改写后的SQL返回的列名、顺序、类型和原查询完全一致，原存储过程才不会报错；
• PostgreSQL：利用pg_rewrite系统表创建查询重写规则，或者用pg_stat_statements捕获高频查询，批量生成改写规则。也可以用自定义的PL/pgSQL函数，在查询前自动替换敏感字段。

3. 轻量级替代：用数据库中间件兜底 #

如果数据库原生工具玩不转，就在应用和数据库之间加一层中间件（比如ShardingSphere、MyCat），中间件负责拦截所有SQL请求：

• 自动识别查询里的敏感表和字段；
• 替换成代理键或者应用匿名化函数；
• 把改写后的SQL发给数据库执行，结果原样返回给应用。
  这种方案完全不用改数据库，对现有架构侵入性极小，适合多数据库分散的场景。

必须注意的几个坑 #

• 性能别踩坑：查询解析和改写会有开销，所以要缓存常用的SELECT语句的改写规则，别每次都重新解析；
• 不可逆是底线：代理键和匿名化处理必须是不可逆的，绝对不能让别人通过代理值反推出真实数据，这是GDPR的核心要求；
• 批量测试：2000多条语句呢，上线前一定要批量跑一遍，确保改写后的结果和原结果结构完全一致，敏感数据都处理到位了。

内容的提问来源于stack exchange，提问作者Woz Turner