在实际业务中，如果数据库中的敏感字段已经加密存储，当需要基于该字段执行模糊查询或搜索时，有哪些可行的实现方案或设计思路？请从技术原理、实现代价和适用场景等方面进行说明。
考察说明
考查候选人对加密数据下模糊搜索技术方案的理解与工程权衡能力。
回答思路
- 【回答框架 1】直接给出核心结论：由于加密后数据失去明文特征，传统 LIKE 语句无法直接在密文上执行模糊匹配，需要额外的索引或预处理机制。常见方案包括：在应用层对明文进行分词后对每个词做精确加密并存储，查询时对关键字做相同加密并执行精确匹配，再在应用层过滤结果；或者使用可搜索加密（如 SSE、OPE、盲索引）与专用数据库扩展（如 MongoDB 字段级加密的确定性加密）。
- 【回答框架 2】方案一（应用层分词加密索引）：将字段内容按词拆分（如中文按 N-Gram 或分词器），对每个词用确定性加密算法（如 AES-SIV）生成密文子串，存入单独索引表或列。查询时对关键字做同样加密，用等值匹配找到候选主键，再一次性解密完整数据做精确过滤。该方案实现简单，查询快，但会泄露部分 token 频率信息，且存储和写入成本增加。
- 【回答框架 3】方案二（可搜索加密算法）：采用保序加密（OPE）或可搜索对称加密（SSE）实现密文下的范围或关键词查询。OPE 支持密文上直接比较，但安全性较弱且无法表达模糊匹配语义；SSE 通常只支持精确关键字，对模糊匹配需设计通配符结构，复杂且效率低，工程上较少直接用于模糊搜索。
- 【回答框架 4】更工程化的替代思路是字段分级处理：将不常用但需模糊查询的字段（如用户名）在加密前加一层哈希索引（对完整值做 HMAC 后存索引），只支持精确匹配查询，同时将模糊搜索需求改为在客户端内存过滤或通过明文副本（如合规脱敏后）处理，需权衡安全合规与查询效率。
- 【关键点 1】密文上直接用 LIKE 无法实现，因为密文不保留可比较的明文字符模式。
- 【关键点 2】分词加密索引可实现近似模糊搜索，核心是标记化与等值匹配。
- 【关键点 3】可搜索加密（OPE/SSE）在理论上有前景，但工程成熟度与性能受限。
- 【关键点 4】实际方案往往结合应用层索引、存储过程或明文副本，并评估安全降级风险。
- 【易错点 1】不要宣称加密可完整支持任意模糊查询，存在明文信息泄露风险。
- 【易错点 2】不要将确定性加密的密文直接用于模糊运算，确定性加密只支持精确比较。
- 【易错点 3】避免引入 OPE 时忽略其保序性带来的统计泄露。