📚 课程目录第4章存量数据加密方案设计

存量数据加密方案设计：三种加密策略的权衡

说实话，做数据加密迁移最头疼的不是算法选型，而是怎么对待那些已经躺了多年的存量数据。我见过太多团队一上来就想全量加密，结果跑了一周还没跑完，业务方天天来拍桌子。今天咱们就聊聊三种主流方案——全量加密、增量加密、字段级加密，各自适用什么场景，坑又在哪里。

全量加密就是把整个数据库或整个文件系统一把梭，所有数据全部重新加密一遍。听起来很痛快，对吧？

我在一个金融项目中就踩过这个坑。当时我们有一个10TB的Oracle库，领导要求周末两天内完成全量加密。结果周六晚上跑了18个小时才发现，某些大表的加密速度只有5MB/s，按这个算得一周。后来怎么处理的？我们只能回滚，改成按表分批加密。

适用场景：

全量加密的核心难点在于——数据量级与时间窗口的矛盾。你想想看，假设你有5TB数据，磁盘I/O带宽是200MB/s，那理论时间就是7小时左右。但实际呢？加密算法CPU消耗、数据库锁争用、网络传输开销……我见过实际性能只有理论值的30%。

指标	全量加密	增量加密	字段级加密
数据范围	全部存量数据	只加密新增/变更部分	仅敏感字段
停机时间	通常需要较长窗口	几乎不影响在线业务	可在线进行
实施复杂度	低	中（需记录偏移量）	高（需改造业务代码）
密钥管理	单一密钥即可	需支持混合密钥版本	可能多字段多密钥
回滚风险	高（数据量大难回退）	低（按批次回滚）	低（只影响部分字段）

增量加密的思路很简单：历史数据先放一放，新写入的数据自动加密，同时后台慢慢地把存量数据“消化”掉。这种方案我特别喜欢用在24小时不停机的业务系统上。

具体怎么做？我习惯分三步走：

我的小技巧：增量迁移时一定要做数据校验。我曾经因为忽略这个步骤，迁移到一半发现某张表的ID有空洞，导致部分数据被反复加密了两次。后来我加了个校验字段——加密前后对原始数据做一次SHA256比对，确保没丢没改。

增量加密的风险主要在于数据一致性。业务还在写入，后台在迁移，万一迁移过程中又有新数据落进来怎么办？我的做法是使用双阶段提交：迁移线程先锁定一行，检查当前时间戳是否大于等于水印，如果条件满足则跳过，否则加密并提交。

字段级加密只针对敏感数据字段，比如身份证号、手机号、银行卡号。其他字段保持明文。这种方案精度最高，但对业务代码的侵入性也最大。

举个例子，你原来的SQL是 SELECT name, id_card FROM users WHERE id = ?，现在 id_card 字段存的是密文，那你查询之后还得解密。如果解密逻辑写在应用层，每个涉及该字段的查询都得改。我见过一个项目，光改这类的SQL就花了一个月。

注意：字段级加密后，数据库的索引和模糊查询会失效。如果你需要在密文上做LIKE查询或者范围查询，必须额外构建可搜索加密方案（比如保留部分明文特征或使用同态加密）。但这又增加了复杂度。

我个人建议，字段级加密只适合少量敏感字段且查询模式固定的场景。比如只通过用户ID精确查询，不需要模糊匹配。如果业务上有大量模糊查询需求，那还是考虑全量加密或用数据库加密扩展（如TDE）更好。

说得再多不如一张图来得直观。下面是我自己总结的决策流程，供你参考：

别以为这三者是互斥的。我在一个电商项目中就用了组合——订单历史数据量太大，全量加密扛不住。我们做了个分层：最近3个月的订单用字段级加密（只加密收件人手机号），3个月到1年的用增量加密后台慢慢搬，超过1年的定期归档时走全量加密。这样既保证了落地合规，又没影响双十一大促。

关键经验：无论选哪种方案，都先在测试环境跑一下性能基线。我习惯把加密速度、CPU占用、I/O延迟、锁等待时间都记录下来，然后用这个数据反推生产环境的窗口够不够。别拍脑袋定时间，我吃过这个亏。