列级加密 vs 表级加密：性能权衡
加密粒度这事儿，说到底就是个选择。你想想看，是只把敏感列锁起来，还是把整张表扔进保险柜？我见过不少团队一开始就想全表加密，觉得省事，结果跑个查询慢了十倍，才回头来问怎么拆。这一章我们就掰开揉碎，看看这两种策略到底差在哪。
加密粒度与性能的关系
先给个直觉：粒度越细，灵活性越高，但代价也越明显。列级加密就像给每个贵重物品单独装锁——你只保护那些几百万的钻石，普通商品随便拿。表级加密则是给整个商场拉下卷帘门——安全是安全了，但就算只想买个饮料也得等卷帘门完全升起。
我习惯从三个维度看性能影响：
- 读写吞吐量：加密和解密消耗CPU，粒度越细，单行处理越多，吞吐越低
- 索引效果：加密后的列在MySQL里基本无法走B-Tree索引（除非你用特殊的可搜索加密方案，但那是另一码事）
- 存储膨胀：有些加密算法会让数据变长，列级更容易看到存储裂缝
核心观点：列级加密的CPU开销在“每行读写”时发生，表级加密的开销在“页面I/O时”发生。两种模式导致完全不同的优化方向。
列级加密实战分析
举个例子。我在金融项目里经常遇到只加密“身份证号”和“手机号”的需求。上层逻辑简单：用 AES_ENCRYPT() 写，用 AES_DECRYPT() 读。但查询的时候就得小心了——你不能直接 where id_card = AES_ENCRYPT('xxx', key)，因为每次加密结果不同（如果用随机IV）。
-- 写入
INSERT INTO users (name, id_card_enc)
VALUES ('张三', AES_ENCRYPT('110101199001011234', @key));
-- 查询（慢！）
SELECT * FROM users
WHERE AES_DECRYPT(id_card_enc, @key) = '110101199001011234';
你看，上面的查询会对全表逐行解密，然后做比较。表一大基本就废了。我建议的做法是：加一个 确定性IV的hash列做索引，比如存 SHA2(id_card_enc, 256) 的前8字节作为查询键。不过这会牺牲一些安全性，属于工程权衡。
我曾经在客户那边见到一个生产事故：他们把手机号列加密后，又给它建了普通B-Tree索引。结果查询计划走了全表扫描，因为MySQL根本不认加密列上的索引范围。切记：加密列上的索引除非是哈希索引配合确定性加密，否则基本没用。
说白了，列级加密最适合那些 低频查询但高频读取 的场景。比如从主键回查某个用户时，只对单行解密，压力很小。
表级加密实战分析
表级加密通常指透明数据加密（TDE），像MySQL企业版或InnoDB的静态加密。它对上层应用完全透明，你不需要改一行SQL，数据库引擎会在将数据页写入磁盘前加密，读入内存时解密。
性能影响呢？我记得在压力测试里，纯读场景大约损失5%~15%的吞吐，写场景稍高一点。原因是页加密发生在“刷脏”的路径上，如果IO本身是瓶颈，那加密额外CPU被IO延迟隐藏掉一部分；如果CPU已经是瓶颈，那加密会让情况更糟。
-- MySQL企业版启用表加密（不更改表定义）
ALTER TABLE orders ENCRYPTION='Y';
-- 或者用keyring插件管理密钥
CREATE TABLE orders (
id INT PRIMARY KEY,
amount DECIMAL(10,2)
) ENCRYPTION='Y';
表级加密最大的好处是 查询路径不受影响。你原有的联合索引、覆盖索引、order by都能正常走。代价是内存中的缓冲池会同时保存加密页和解密页吗？其实不是——页在内存里是明文的，刷盘时才加密，读盘后立即解密。所以热数据完全无解密开销。
如果你用TDE，记得把密钥缓存和心跳监控做好。我有一次线上遇到keyring故障，数据库启动时无法解密redo log，差点需要从备份恢复——那感觉太酸爽了。
两种策略的对比
| 维度 | 列级加密 | 表级加密（TDE） |
|---|---|---|
| 加密粒度 | 单列/多列 | 整表数据页 |
| 应用侵入性 | 高，需改SQL与密钥管理 | 低，完全透明 |
| 索引兼容性 | 差，需特殊设计（哈希索引+确定性IV） | 好，原索引全可用 |
| CPU消耗位置 | 每次读写行时 | 每次刷盘/读取数据页时 |
| 典型性能损失 | 点查5~10%，范围查可达80% | 持续均匀5~15% |
| 适用场景 | 少数高敏感列，低频查询 | 大部分数据需保护，保留完整查询能力 |
如何选择？一张图说清
下面这张图是我画的一个决策框架。你顺着走，基本不跑偏。
我个人习惯这样判断：如果超过两列都是敏感字段，或者业务经常要where加密列，我直接选TDE。只有那种纯展示型字段（比如用户详情页才展示的身份证），才适合单独列加密。
别忘了合规要求！GDPR、PCI-DSS可能明确要求字段级遮盖或加密。如果只能选列级加密，那你就得接受索引性能的牺牲——提前和业务方说清楚：这个搜索功能可能要慢三倍，但他们必须认。
嗯，总结一下：没有银弹。列级加密给你手术刀般的控制力，但削到索引筋骨；表级加密给你稳定全面的保护，但代价是均匀的CPU消耗。建议你在PoC阶段分别压测两种模式，用真实的查询负载说话——别信任何人的“最佳实践”，只信你自己的压测曲线。