列级加密与行级加密：区别与适用场景
咱们聊性能调优，加密策略选错了，后面怎么优化都白搭。这一章我重点说说列级加密和行级加密，这两个概念很多人搞混。我见过不少项目，因为选错了加密粒度，性能翻车，最后不得不重构。
说白了，列级加密就是只加密表中的某个字段，比如信用卡号。行级加密是把一整行数据打包加密。你想想看，这两种方式对查询性能的影响天差地别。
先说列级加密
列级加密是目前用得最广的方式。我习惯在定义表结构时就指定加密列。比如下面这个例子：
-- 创建表时指定加密列
CREATE TABLE payment_info (
id INT PRIMARY KEY,
customer_name VARCHAR(100),
cc_number ENCRYPTED WITH (algorithm = AES_256, key = 'myKey1'),
expiry_date DATE,
cvv_code ENCRYPTED WITH (algorithm = AES_256, key = 'myKey2')
);这样写，只有 cc_number 和 cvv_code 被加密。查询其他字段时，数据库完全不用操心解密的事。我在项目中遇到过这样一个场景：电商系统的订单表，几十个字段里只有信用卡号需要保护。列级加密完美解决，查询性能损耗几乎可以忽略。
再说行级加密
行级加密就不一样了。它把一行的所有字段打包成一个加密单元。说白了，你要看某个字段，得先把整行数据全部解密。像这样：
-- 插入加密行
INSERT INTO medical_record VALUES (
ENCRYPT('patient_name, diagnosis, prescription', 'row_key_001')
);这种方式的粒度更粗。我有个血泪教训：之前帮一家医院做系统，他们把患者所有病历字段都用行级加密。结果医生只想查个过敏史，系统必须解密整行数据。几百行记录查下来，响应时间直接飙到秒级。
核心区别对比
我把两种方式的差异梳理成一张表，方便你对照：
| 维度 | 列级加密 | 行级加密 |
|---|---|---|
| 加密粒度 | 字段级别 | 行级别 |
| 解密开销 | 仅操作目标列 | 必须全行解密 |
| 查询性能 | 高（索引可用） | 低（索引失效） |
| 密钥数量 | 可为每列独立密钥 | 通常共享行密钥 |
| 适用场景 | 少量敏感字段 | 整行数据都敏感 |
| 管理复杂度 | 中 | 低（全局密钥） |
什么时候用哪个？
我一般这样判断：
- 列级加密优先：90% 的场景用这个就够了。比如用户表只加密密码字段，商品表只加密成本价格。列级加密能利用索引，查询性能影响小。
- 行级加密备选：只有整行数据都是敏感信息时才考虑。比如加密的审计日志、加密的全病历记录。注意，这种情况下查询能力会大幅受限。
关键判断准则： 如果表中超过 60% 的列都需要加密，行级加密反而更简单。否则，列级加密性能优势明显。
一个真实案例
我记得有个在线支付项目，需要保护用户的银行卡信息和交易备注。银行卡信息必须加密，交易备注只是为了系统内部审计，不需要加密。我推荐用列级加密，只加密银行卡号列。为什么呢？
- 查询交易备注时，数据库零解密开销。
- 按用户 ID 检索时，索引正常工作。
- 密钥管理简单，一把密钥搞定。
如果换作行级加密，每次查交易备注都得解密整行，性能损失至少 3 倍。所以别偷懒，选对粒度能省很多事。
WHERE 条件里直接过滤加密字段。比如 WHERE cc_number = '1234' 会变成全表扫描+逐行解密。这是性能杀手。
嗯，总结就一句：列级加密性能好但管理成本略高，行级加密简单粗暴但查询能力打折。没有的好坏，只有适不适合你的场景。选择之前，先想清楚你的查询模式和敏感数据分布。