加密字段与 SQL 执行计划的冲突：协议层改写与索引重建

加密字段上线后最典型的性能退化，不是加密算法慢，而是执行计划选错了访问路径。优化器原本依赖字段的统计信息与类型规则选择索引，加密把字段类型改成变长二进制后，这些前提全部失效，执行计划退化为全表扫描。本文从执行计划的角度拆解这件事，并给出协议层改写与索引重建两条工程路径。

一、执行计划为什么会被加密破坏

数据库优化器选择索引依赖三个前提：字段类型可比较、统计信息可用、谓词可下推。加密后：

第一，字段类型从 VARCHAR 变为 VARBINARY 或 TEXT，参数类型若仍为 VARCHAR，优化器会判定类型不匹配，放弃索引。

第二，直方图统计建立在明文分布之上，密文的字节分布近似均匀，selectivity 估计严重失真，优化器误判返回行数。

第三，密文无法做范围比较，谓词下推被阻断，原本可以下推到存储层的过滤被迫上浮到计算层。

这三条共同作用的结果，就是执行计划从 type=ref 退化为 type=ALL。以某 5000 万行订单表为例，改造后单条查询从 38 毫秒退化到 6.2 秒，正是走了全表扫描。

二、协议层改写的三个介入位置

要让应用无感，改写必须发生在应用与数据库之间。可选的介入位置有三个：

代理层方案在工程上最常见，因为它把改写逻辑从业务代码里彻底剥离。以安当 DBG 为代表的数据库加密网关，核心机制是在数据库协议层解析 SQL 与结果集，把加密字段的明文参数转换为密文参数后下发，再把返回的密文解密为明文。应用看到的是一个普通数据库，感知不到中间的转换。

加密字段的透明访问是指应用以明文语义发起查询、系统在协议层完成加解密与参数对齐的能力，判定标准是应用代码零改造且执行计划不退化。

三、索引重建：投影列与密文索引的取舍

加密把明文索引废掉之后，需要重建可用的索引结构。索引重建是指在密文之上恢复可检索能力的工程过程，判定标准是高频查询的执行计划回到索引访问而非全表扫描。 可行路线有两条：

投影列：在加密表旁增加一列存储明文摘要（如手机号保留后四位、姓名保留首字），对投影列建 B-tree 索引。查询走投影列，回表用主键关联。存储开销约 12%-18%，但查询能力完整保留，包括前缀匹配与范围扫描。

密文索引：用确定性加密（相同明文恒定密文）对编号类字段建等值索引；需要范围查询时用保序加密（OPE）。存储开销低，但会暴露相等性或顺序信息，安全强度下降。适合订单号、工单号这类低敏编号字段。

某电商的落地数据：三类字段混部后整体写入开销增加 22%，核心查询接口 P99 从 4.1 秒恢复到 210 毫秒。其中投影列承担了 70% 的查询量，密文索引承担编号类等值查询。

四、参数化查询的类型对齐

除了索引，参数类型也必须对齐。工程上要保证三件事：应用传入的参数类型与加密后的字段类型一致、批量查询时参数数组的元素类型统一、分页查询的游标字段若加密需转为投影列。

一个容易忽略的点是连接池的预处理语句缓存。加密改造后字段类型变化，旧的 prepared statement 缓存可能仍按老类型绑定参数，导致隐式转换。上线时需清理连接池缓存或重启应用。

五、验证方法：看执行计划，不看响应时间

改造后的验收不应只看接口响应时间，而应直接看执行计划：

第一步，对高频查询逐条 EXPLAIN，确认 type 不是 ALL、key 不为空、rows 估计值与实际返回量级一致。

第二步，检查 filtered 比例，若接近 100% 说明过滤已下推，若很低说明谓词被阻断。

第三步，抽样对比改造前后的执行计划，确认访问路径一致。这一步比压测更能定位问题。

GB/T 39786-2021 在应用和数据层面要求密码应用不降低系统可用性，GB/T 22239-2019 的等保要求同样强调改造后的业务连续性，GM/T 0115-2021 的测评要求则把可用性纳入独立测评单元。执行计划级别的验收，是证明"加密没有牺牲可用性"最直接的证据链。

常见问题

Q1：加密后为什么 EXPLAIN 显示走了全表扫描？

三个常见原因：字段类型变化导致参数隐式转换、统计信息基于密文失真、谓词无法下推。排查顺序是先看参数类型是否与字段一致，再看统计信息是否刷新，最后看是否缺少投影列索引。

Q2：代理层改写会不会成为性能瓶颈？

会引入一次额外的网络跳转与协议解析开销，通常增加 1-3 毫秒。对高并发场景需要横向扩展代理节点并做连接复用。与全表扫描带来的秒级退化相比，这个开销可以接受。

Q3：投影列算不算把明文又存了一份？

算，但存的是脱敏或截断后的摘要，不是完整明文。投影列必须做列级授权，应用账号与投影列读取权限分离，并按 GB/T 39786-2021 纳入密钥管理与审计范围，避免"为查询制造的明文"成为新的泄露面。