前言
应用层加密，指加解密逻辑完全在业务服务代码中执行（Python/Java/Go等），明文不会传递到MySQL，数据库只负责存储密文二进制数据。密钥全程不经过数据库、不写入SQL、不会出现在binlog/慢查询日志。
✅ 优点
1. 安全上限最高，可以抵御数据库内部人员越权查看
这是最核心优势。
数据库里只存密文。即使DBA、运维拿到数据库账号，导出全量数据、拿到备份文件，没有密钥就无法还原敏感明文。
- MySQL内置AES函数：密钥写在SQL，日志会泄露；
- TDE透明加密：DBA登录数据库查询直接返回明文；
- 应用层加密：数据库侧全程看不到原始敏感数据。
2. 不受MySQL版本、数据库类型限制
加解密和数据库解耦。MySQL5.7、8.0，甚至PostgreSQL、SQL Server都可以用这套逻辑；后期迁移数据库，加密逻辑不用大改。
可以自由选择加密算法：AES-GCM、SM4国密等，不受数据库内置函数的算法限制。
3. 密钥不会暴露在SQL、binlog、慢日志中
明文在应用内存完成加密，传给数据库的只有密文。SQL语句里不存在密钥，binlog、慢查询日志、审计日志都不会记录密钥，大幅降低密钥泄露风险。
4. 灵活可控，可自定义加密策略
- 可以对不同业务、不同敏感等级数据使用不同密钥；
- 可以增加数据完整性校验（GCM模式自带MAC校验，防止密文被篡改）；
- 可以统一在应用层做脱敏、审计，数据库层无需改造。
5. 支持密钥轮换
密钥轮换是安全规范要求。密钥变更时，只需要应用层分批重加密历史数据，不需要修改数据库配置，相比MySQL原生列加密、TDE更加灵活。
❌ 缺点
1. 增加业务开发工作量
需要自己实现/封装加解密工具类，处理：
- IV（随机向量）、tag校验信息存储；
- 异常捕获（密文损坏、密钥错误导致解密失败）；
- 历史数据批量迁移加密脚本；
- 新增哈希字段用于等值查询。
开发、单元测试、联调都需要额外投入。
2. 密文字段无法直接在数据库做模糊查询、范围查询
密文是随机二进制，数据库不能直接使用 LIKE、> < 对密文检索。
- 等值查询：需要额外增加哈希摘要字段（SHA256）；
- 模糊检索：只能业务层解密后过滤（大数据量性能很差），或者单独存储脱敏片段（手机号前3后4）。
3. 应用服务器CPU开销
大量写入、查询敏感数据时，加解密会消耗应用服务器CPU。
少量敏感字段影响很小；如果大批量数据并发加解密，需要评估应用服务器性能，必要时做缓存。
4. 密钥管理压力转移到业务侧
密钥不再由MySQL管理，业务需要配套密钥管理方案：
- 禁止硬编码密钥；
- 对接KMS密钥管理服务；
- 密钥备份、权限、轮换、密钥泄露应急方案；
一旦密钥丢失，对应敏感数据永久无法解密。
5. 数据迁移、同步组件需要适配
- 数据同步工具（canal、dts）读取到的都是密文，无法直接解析敏感内容；
- 数据导出、报表、数据仓库同步时，需要走应用层解密接口，不能直接读库。
📌 适用场景总结
适合：
- 用户隐私信息（身份证、手机号、银行卡），需要防止DBA/内部运维越权读取；
- 等保、隐私合规要求高的业务；
- 多数据库、需要自主选择国密/AES算法。
不适合：
- 敏感字段需要大量模糊检索、范围查询，且无法新增哈希/脱敏辅助字段；
- 小项目无人力维护密钥管理、加解密逻辑；
- 海量数据场景，应用CPU资源紧张。
小结
一句话概括：应用层加密牺牲一定开发成本、查询能力，换取最高的数据安全等级，是生产环境敏感隐私字段的首选方案，但必须配套做好密钥管理。