咱们知道加密后的数据对含糊查问不是很友好，本篇就针对加密数据含糊查问这个疑问来倒退讲一讲成功的思绪，宿愿对大家有所启示。
一、背景
为了数据安保咱们在开发环节中经常会对关键的数据启动加密存储，经常出现的有：明码、手机号、电话号码、详细地址、银行卡号、信誉卡验证码等信息，这些信息对加解密的要求也不一样，比如说明码咱们须要加密存储，普通经常使用的都是无法逆的慢hash算法，慢hash算法可以防止暴力破解（典型的用时期换安保性）。
在检索时咱们既不须要解密也不须要含糊查找，间接经常使用密文齐全婚配，然而手机号就不能这样做，由于手机号咱们要检查原信息，并且对手机号还须要允许含糊查找，因此咱们当天就针对可逆加解密的数据允许含糊查问来看看有哪些成功形式。
在网上随意搜查了一下，关于《加密后的含糊查问》 的帖子很多，顺便整顿了一下成功的方法，不得不说很多都是不靠谱的做法，甚至有一些沙雕做法，接上去咱们就对这些做法来讲讲成功思绪和优劣性。
二、如何对加密后的数据启动含糊查问
我整顿了一下对加密的数据含糊查问大抵分为三类做法，如下所示：
咱们就对这三种成功方法逐一来讲讲成功思绪和优劣性，首先咱们先看沙雕做法。
沙雕做法
沙雕一
咱们先来看看第一个做法，将一切数据加载到内存中启动解密，这个假设数据量小的话可以经常使用这个形式来做，这样做既繁难又实惠，假设数据量大的话那就是劫难，咱们来大抵算一下。
一个英文字母(不分大小写)占一个字节的空间，一个中文汉字占两个字节的空间，用DES来举例，13800138000加密后的串HE9T75xNx6c5yLmS5l4r6Q==占24个字节。
|
条数 |
|
|
2万 |
|
|
2.4亿 |
|
|
1亿 |
24亿 |
轻则上百兆，重则上千兆，这样分分钟给运行程序整成Out of memory，这样做假设数据少只要几百、几千、几万条时是齐全可以这样做的，然而数据量大就剧烈不倡导了。
沙雕二
咱们再来看第二个做法，将密文数据映射一份明文映射表，而后含糊查问映射表来关联密文数据，what？？？！！！那咱们为什么要对数据加密呢，间接不加密不是更好么！
咱们既然对数据加密必需是有安保诉求才会这样做，参与一个明文的映射表就违反了安保诉求，这样做既不安保也不繁难齐全是脱裤子放x，多此一举，强且不介绍。
惯例做法
咱们接上去看看惯例的做法，也是最宽泛经常使用的方法，此类方法及满足的数据安保性，又对查问友好。
惯例一
在数据库中成功与程序分歧的加解密算法，修正含糊查问条件，经常使用数据库加解密函数先解密再含糊查找，这样做的好处是成功老本低，开发经常使用老本低，只要要将以往的含糊查找稍微修正一下就可以成功，然而缺陷也很显著，这样做无法应用数据库的索引来提升查问，甚至有一些数据库或许无法保证与程序成功分歧的加解密算法，然而关于惯例的加解密算法都可以保证与运行程序分歧。
假设对查问性能要求不是特意高、对数据安保性要求普通，可以经常使用经常出现的加解密算法比如说AES、DES之类的也是一个不错的选用。
假设公司有自己的算法成功，并且没有提供多端的算法成功，要么找个算法好的人去钻研吃透补全多端成功，要么丢弃经常使用这个方法。
惯例二
对密文数据启动分词组合，将分词组合的结果集区分启动加密，而后存储到裁减列，查问时经过key like '%partial%'，这是一个比拟划算的成功方法，咱们先来剖析一下它的成功思绪。
先对字符启动固定长度的分组，将一个字段拆分为多个，比如说依据4位英文字符（半角），2个中文字符（全角）为一个检索条件，举个例子：
假设须要检索一切蕴含检索条件4个字符的数据比如：ingy ，加密字符后经过key like “%partial%”查库。
咱们都知道加密后长度会增长，增长的这局部长度存储就是咱们要破费的额外老本，典型的经常使用成原本换取速度，密文增长的幅度随着算法不同而不同以DES举例，13800138000加密前占11个字节，加密后的串HE9T75xNx6c5yLmS5l4r6Q==占24个字节，增长是2.18倍，所以一个低劣的算法是如许的关键，能为公司节俭不少老本，然而话又说回来算法工程师的工资也不低，所以我也不知道是节俭老本还是参与老本，哈哈哈…你们自己算吧。
回到主题，这个方法尽管可以成功加密数据的含糊查问，然而对含糊查问的字符长度是有要求的，以我上方举的例子含糊查问字符原文长度必需大于等于4个英文/数字，或许2个汉字，再短的长度不倡导允许，由于分词组合会增多从而造成存储的老本参与，反而安保性降落。
大家能否都对接过 淘宝、拼多多、JD他们的api，他们对平台订复数据中的用户敏感数据就是加密的同时允许含糊查问，经常使用就是这个方法，上方我整顿了几家电商平台的密文字段检索打算的说明，感兴味的可以检查上方链接。
这个方法好处就是成功起来不算复杂，经常使用起来也较为繁难，算是一个折中的做法，由于会有裁减字段存储老本会有升高，然而可应用数据库索引提升查问速度，介绍经常使用这个方法。
超神做法
咱们接上去看看低劣的做法，此类做法难度较高，都是从算法层面来思索，有些甚至会设计一个新算法，尽管已有一些现成的算法参考，然而大多都是半成品无法拿来间接经常使用，所以还是要有人去深化钻研和整合到自己的运行中去。
从算法层面思索，甚至会设计一个新算法来允许含糊查找
这个层面大多是专业算法工程师的钻研畛域，想要设计一个有序的、非无法逆的、密文长度不能增长过快的算法不是一件繁难的事情，大抵的思绪是这样的，经常使用译码的形式启动加解密，保管密文和原文一样的顺序，从而允许密文含糊婚配，说的比拟抽象由于我也不是这方面的专家没有更深一步的钻研过，所以我从网上找了一些资料可以参考一下。
这里提到的Hill明码解决和含糊婚配加密方法FMES可以重点看看.
基于Lucene的思绪就跟咱们上方引见的惯例做法二相似，对字符启动等长度分词，将分词后的结果集加密后存储，只不过存储的db不一样，一个是相关型数据库，一个是es搜查引擎。
三、总结
咱们到这里对加密数据的检索打算所有引见完了，咱们首先提到的是网上搜查随处可见的沙雕做法，在这里也讲了不介绍经常使用这些沙雕做法，尽量经常使用惯例做法，假设公司有专业算法方向人才的话无妨可以思索基于算法层面的超神做法。
总的来说从投入、产出比、及成功、经常使用成原本算的话惯例做法二是十分介绍的。