如何实现数据库表指定列查询自动解密、写入自动加密？

核心逻辑是把加解密能力下沉到数据库侧，对应用完全透明，现有SQL语句不需要做任何调整就能满足自动加解密需求，以下是三种可直接落地的方案，按改造成本从低到高排序：

方案1：视图+触发器（全数据库通用，改造成本最低） #

这是兼容性最好的方案，支持MySQL、PostgreSQL、SQL Server等绝大多数主流数据库，不需要升级数据库版本，也不需要额外部署组件：

• 先将现有users表重命名为users_encrypted，作为实际存储密文的物理表，先跑批把表内已有的email、phone、password字段全量加密存储。
• 创建和原表名完全一致的视图users，视图查询时自动调用解密函数输出明文，以MySQL为例的视图定义：

  CREATE VIEW users AS
  SELECT
    id,
    user_name,
    AES_DECRYPT(email, @enc_secret_key) AS email,
    AES_DECRYPT(phone, @enc_secret_key) AS phone,
    AES_DECRYPT(password, @enc_secret_key) AS password,
    created_at,
    updated_at
  FROM users_encrypted;
  

  其中@enc_secret_key是提前配置好的数据库全局变量，存储加密密钥，避免密钥硬编码在视图定义里泄露。
• 给视图创建INSTEAD OF触发器，拦截所有针对视图的INSERT、UPDATE操作，自动把传入的明文加密后写入底层物理表，INSERT触发器核心逻辑示例：

  -- 触发器触发逻辑：拦截视图写入
  FOR EACH ROW
  BEGIN
    INSERT INTO users_encrypted (user_name, email, phone, password, created_at, updated_at)
    VALUES (
      NEW.user_name,
      AES_ENCRYPT(NEW.email, @enc_secret_key),
      AES_ENCRYPT(NEW.phone, @enc_secret_key),
      AES_ENCRYPT(NEW.password, @enc_secret_key),
      NOW(),
      NOW()
    );
  END
  

  UPDATE操作的触发器逻辑同理，对SET传入的明文值加密后更新到底层表即可。

配置完成后，应用侧执行的所有SELECT、INSERT、UPDATE语句和之前完全一致，查询自动返回明文，写入自动加密存储，不需要改一行应用代码。

方案2：数据库原生列加密特性（性能最优） #

如果你的数据库是较新的版本，可以直接用原生功能替代手写的视图和触发器，性能损耗更低：

• PostgreSQL：启用pgcrypto扩展后，可通过列级加密+规则（RULE）实现透明加解密，比触发器性能高15%左右；
• MySQL 8.0+：可使用不可见列存储密文，搭配虚拟生成列自动解密输出，给写入操作创建触发器即可，不需要额外建视图；
• Oracle/SQL Server：直接使用原生的列级透明加密（TDE）、动态数据掩码功能，只需要给对应列配置加密规则和访问权限，授权普通账号查询时自动返回明文，写入自动加密，不需要自定义任何函数、触发器。

方案3：数据库代理层加解密（零数据库侵入） #

如果不方便修改数据库内的表、视图、触发器配置，可以在应用和数据库之间部署一层数据库代理（比如ProxySQL、MaxScale）：

• 代理拦截所有发往users表的SQL请求
• 识别到SELECT语句查询加密列时，自动改写SQL，给对应字段加上解密函数
• 识别到INSERT/UPDATE语句写入加密列时，自动改写SQL，给传入的明文参数加上加密函数
• 代理将改写后的SQL转发给数据库执行，再把结果返回给应用
  这种方案完全不侵入数据库，密钥可以存储在代理侧，避免数据库被拖库时密钥同时泄露，安全性更高，适合数据库权限管控严格的场景。

落地注意事项 #

• 对称加密算法优先选AES-256-GCM，加解密速度快，支持校验，避免密文被篡改；
• 密钥不要和加密数据存在同一个数据库实例，建议存在独立的配置中心或者只有超级管理员可读的密钥表；
• 全量切换前要先做数据备份，先在测试环境验证加解密结果一致、SQL执行无报错，再切生产流量。

内容的提问来源于stack exchange，提问作者Rahul Kumar