加密字段模糊查询工程实践：密文索引、分词映射与明文列三种路线加密字段模糊查询工程实践：密文索引、分词映射与明文列三种路线

一、问题建模：模糊查询失效的根因

以 SM4（GM/T 0002-2012）为代表的对称分组加密具有雪崩效应：明文中一个字节的变化会引起约 50% 密文字节变化。这决定了加密字段上 LIKE '%keyword%' 不可能走索引——通配符匹配依赖明文的字节连续性，而密文中不存在任何连续片段。工程上的解法只有三类：保留可检索的明文投影、建立密文到明文的等价映射、或将匹配条件下推到应用层前置处理。

三条路线不是互斥的，生产系统通常按字段粒度混合使用。下文逐条给出构建方法。

二、路线一：明文列（投影列）

在加密表旁增加投影列，存储脱敏或截断的明文，模糊查询走投影列，回表时用等值关联。

• 构建：ALTER TABLE customer ADD phone_mask CHAR(11)，写入时由中间件同步填充 138****5678 格式
• 索引：对投影列建 B-tree 或前缀索引，WHERE phone_mask LIKE '138%' 可走索引范围扫描
• 权限：投影列必须做列级授权，应用账号与投影列读取权限分离
• 代价：存储增加约 15%-20%（11 字节/行），写入路径多一次字段派生

实测数据：某 5000 万行用户表，后四位模糊查询从全表扫描 4.2 秒降至索引扫描 38 毫秒；投影列权限收敛后，未授权账号直接读取明文列返回空结果集。

投影列可用性是指加密字段通过受限明文投影恢复约定模式匹配的能力，判定标准是查询响应时间与投影列的权限隔离有效性。

三、路线二：分词映射表

对长文本字段预分词，每个词元单独加密后存入映射表，查询时加密词元后做集合匹配。

• 构建：写入路径增加分词与加密两个环节，映射表结构为 (doc_id, token_cipher, position)，token 用确定性加密保证相同词元得到相同密文；词元加密所用密码模块按 GM/T 0028-2014 对应等级建设，与数据密钥分层管理
• 查询：LIKE '%合同%' 转换为加密 ENC('合同') 后查映射表，命中 doc_id 集合再回表
• 代价：写入放大 3-5 倍，映射表体积随词元数线性增长；100 万字文档约产生 120 万词元记录
• 适用：合同正文、备注、工单描述等包含匹配为主的字段

工程要点：词元加密建议独立密钥（与数据密钥分层），映射表自身要做访问控制——它等价于一份可检索的明文索引，是审计重点。分词映射是指将长文本切分为词元后逐词元加密建索引的检索机制，判定标准是词元密文的可检索性与原文本的不可还原性。

四、路线三：密文索引（确定性加密 + 有序保序加密）

对编号类字段（订单号、身份证号）用确定性加密（相同明文恒定密文）建立等值索引；需要范围查询时用保序加密（OPE）方案。

安全边界必须写清楚：确定性加密会暴露"两行数据该字段相同"这一信息，OPE 进一步暴露大小关系。因此仅建议用于低敏感度编号类字段；身份证号等高敏字段推荐走令牌化映射服务，密文随机且不可分析。

五、混合方案与落地参数

生产推荐的分层策略：

1. 高敏编号类（身份证、银行卡）→ 令牌化映射，密文随机
2. 中敏编号类（订单号、工单号）→ 确定性加密 + 密文索引
3. 长文本（合同、备注）→ 分词映射，词元独立密钥
4. 高频展示字段（手机号、姓名）→ 明文投影列，严格列级授权

改造顺序上，新系统在 schema 设计阶段一次性规划四类字段；存量系统按"投影列先行（改造量最小）→ 分词映射（收益最大）→ 令牌化（安全补齐）"推进。每类改造上线后用同一组指标验收：查询 P99 延迟、写入吞吐变化、未授权访问拦截记录。投影列与映射表作为明文投影，按 GB/T 39786-2021 应用和数据层面的要求纳入密钥管理与审计范围，避免"为了查询而制造的明文"成为新的泄露面。

某中型电商的落地数据：三类混部后整体写入开销 22%，核心搜索接口 P99 从改造前的 4.1 秒恢复到 210 毫秒，且全年渗透测试未发现明文投影列的越权读取。

加密字段的查询能力不是"有或没有"，而是"按字段粒度选择代价"。把四类字段分清楚，模糊查询和保密性就不再是二选一。你们的加密表用了哪种索引路线？评论区交流实现细节。