1. 应用加密 SDK 简介与索引基本概念
加密 SDK，说白了就是帮你在应用层把数据“锁起来”的一套工具包。你传进去明文字段，它吐出来密文，再存到数据库里。听起来挺简单对吧？但一旦涉及到查询，问题就来了——数据库的索引，默认可不认加密后的乱码。
我做过好几个项目，前期都没太在意这层关系。结果上线一跑，某个加密字段的查询慢到让人崩溃。嗯，从那以后我再也不敢忽略索引的兼容问题了。
核心观点：索引兼容性，是加密 SDK 能否在真实业务中落地的关键瓶颈。
1.1 什么是应用加密 SDK
应用加密 SDK 是一组库和接口，专门用来对应用层的敏感数据做加密/解密。常见的场景包括：
- 手机号、身份证等 PII 数据 – 脱敏存储，防泄露。
- 金融交易中的卡号、余额 – 满足合规要求。
- 业务日志中的敏感字段 – 防止运维人员直接看到明文。
加密方式多种多样，比如 AES、SM4，甚至结合了密钥管理服务。但无论哪种，最终存到数据库里的都是密文。
记住：加密后的数据通常是“随机化”的，长度也可能变长。这对索引结构的影响，远比你想的大。
1.2 索引为什么在加密场景下“翻车”
数据库的索引（比如 MySQL 的 B+ 树，MongoDB 的普通索引）依赖于数据的 可比较性。你让它排个序，它需要知道“a”比“b”小。但密文呢？同一个明文加密两次，得到的密文都可能不一样（如果用了随机 IV）。
我遇到过一种情况：某个字段用 AES-256-CBC 加密，每行数据加密时都生成新 IV。结果在这个字段上建了普通索引后，查询永远走不了索引——因为密文不相等。你想想看，哪怕你输入完全相同的明文，存储的密文也完全不同。索引就没法帮你直接定位。
常见的索引兼容问题有这几类：
- 随机化加密导致索引失效 – 无法直接利用等值查询。
- 密文长度膨胀 – 索引页装不下更多记录，IO 增加。
- 排序/范围查询无法实现 – B+ 树需要有序密文，但加密后顺序全乱了。
- 部分加密算法破坏索引结构 – 比如某些加密模式会自动填充，造成歧义。
1.3 索引的基本概念回顾
不管你用哪种数据库，索引的核心目的都一样：加速数据定位。下面这个表格对比了几种常见索引在加密场景下的表现，你可以一目了然：
| 索引类型 | 原理 | 加密场景下的问题 | 我踩过的坑 |
|---|---|---|---|
| B+树索引 | 有序排列，支持范围查询 | 密文无序，无法维持 B+树结构 | 一次为加密字段建了普通索引，查询走了全表扫描 |
| 哈希索引 | 直接映射，等值查询极快 | 需要稳定哈希值，但随机化加密导致每次不同 | 哈希索引看似能用，但密钥轮换后全废了 |
| 全文索引 | 分词+倒排 | 密文分词无意义，索引基本不可用 | 某次想对加密的地址字段做全文检索，放弃 |
| 位图索引 | 按位标记 | 密文无固定基数，位图效率极差 | 只在少量离散值场景可用，加密后基本不用 |
注意：不要在随机化加密的字段上直接建普通索引。你需要先考虑业务查询模式，再决定用“可搜索加密”技术或者“密文等值索引”。
1.4 加密场景下的索引“兼容”到底是什么
说白了，就是让你那个加密后的字段，在索引上“看起来”还是有序的、可比较的、可匹配的。这背后有几种思路：
- 确定性加密 – 同样的明文永远产生同样的密文（比如 AES-SIV 模式）。这样等值查询可以走普通索引。
- 密文保持顺序 – 密文的大小关系与明文一致（OPE 保序加密）。范围查询也能走索引。
- 构建额外索引表 – 在加密 SDK 层面维护一个 索引，辅助查询。
我个人的习惯是：先确定业务真的需要直接在加密字段上建索引，还是可以换个方式（比如在应用层先解密再查询）。后者虽然性能差，但架构简单。如果非要建，我建议用确定性加密方案，并配合适当的分表策略。
1.5 本章知识体系总览
下面这张图把本章涉及的核心概念串在了一起。你会发现所有问题都围绕一个矛盾：加密的随机性 vs 索引的有序性。
图的重点在于：不管你选哪种加密方式，最终都需要和索引结构“握手”。如果握手失败，就出现兼容问题。我们后面的章节会逐一拆解这些握手失败的具体原因和修补方法。
如果你现在正被加密索引问题困扰，可以从这张图里找到自己的现状定位——先看清楚是加密方式的问题，还是索引类型选错了，再对症下药。
好了，这一章主要是铺垫，把概念讲清楚。我从一个真实案例出发，介绍了加密 SDK 和索引之间的冲突，也明确了“兼容”到底指什么。后面的章节会深入到每一种加密方案的索引实现细节，以及那些我在实际项目中踩过的坑和解决方法。