加密后的数据如何进行模糊查询

加密后的敏感字段如何进行模糊查询

一、加密后的数据如何进行模糊查询

加密后的数据对模糊查询不是很友好，本篇就针对加密数据模糊查询这个问题来展开讲一讲实现的思路

为了数据安全我们在开发过程中经常会对重要的数据进行加密存储，常见的有：密码、手机号、电话号码、详细地址、银行卡号、信用卡验证码等信息，这些信息对加解密的要求也不一样，比如说密码我们需要加密存储，一般使用的都是不可逆的慢hash算法，慢hash算法可以避免暴力破解（典型的用时间换安全性）

在检索时我们既不需要解密也不需要模糊查找，直接使用密文完全匹配，但是手机号就不能这样做，因为手机号我们要查看原信息，并且对手机号还需要支持模糊查找，因此我们今天就针对可逆加解密的数据支持模糊查询来看看有哪些实现方式

在网上随便搜索了一下，关于《加密后的模糊查询》 的帖子很多，顺便整理了一下实现的方法，不得不说很多都是不靠谱的做法，甚至有一些沙雕做法，接下来我们就对这些做法来讲讲实现思路和优劣性

1、如何对加密后的数据进行模糊查询

我整理了一下对加密的数据模糊查询大致分为三类做法，如下所示：

• 沙雕做法（不动脑思考直男的思路，只管实现功能从不深入思考问题）
• 常规做法（思考了查询性能问题，也会使用一些存储空间换性能等做法）
• 超神做法（比较高端的做法从算法层面上思考）

我们就对这三种实现方法一一来讲讲实现思路和优劣性，首先我们先看沙雕做法

2、沙雕做法

• 将所有数据加载到内存中进行解密，解密后通过程序算法来模糊匹配
• 将密文数据映射一份明文映射表，俗称tag表，然后模糊查询tag来关联密文数据

2.1、沙雕一

我们先来看看第一个做法，将所有数据加载到内存中进行解密，这个如果数据量小的话可以使用这个方式来做，这样做既简单又实惠，如果数据量大的话那就是灾难，我们来大致算一下

一个英文字母(不分大小写)占一个字节的空间，一个中文汉字占两个字节的空间，用DES来举例，13800138000加密后的串HE9T75xNx6c5yLmS5l4r6Q==占24个字节

轻则上百兆，重则上千兆，这样分分钟给应用程序整成Out of memory，这样做如果数据少只有几百、几千、几万条时是完全可以这样做的，但是数据量大就强烈不建议了

2.2、沙雕二

我们再来看第二个做法，将密文数据映射一份明文映射表，然后模糊查询映射表来关联密文数据，what？？？！！！那我们为什么要对数据加密呢，直接不加密不是更好么

我们既然对数据加密肯定是有安全诉求才会这样做，增加一个明文的映射表就违背了安全诉求，这样做既不安全也不方便完全是脱裤子放x，多此一举，强且不推荐

3、常规做法

我们接下来看看常规的做法，也是最广泛使用的方法，此类方法及满足的数据安全性，又对查询友好

在数据库实现加密算法函数，在模糊查询的时候使用decode(key) like '%partial%
对密文数据进行分词组合，将分词组合的结果集分别进行加密，然后存储到扩展列，查询时通过key like '%partial%'

3.1、常规一

在数据库中实现与程序一致的加解密算法，修改模糊查询条件，使用数据库加解密函数先解密再模糊查找，这样做的优点是实现成本低，开发使用成本低，只需要将以往的模糊查找稍微修改一下就可以实现，但是缺点也很明显，这样做无法利用数据库的索引来优化查询，甚至有一些数据库可能无法保证与程序实现一致的加解密算法，但是对于常规的加解密算法都可以保证与应用程序一致

如果对查询性能要求不是特别高、对数据安全性要求一般，可以使用常见的加解密算法比如说AES、DES之类的也是一个不错的选择

如果公司有自己的算法实现，并且没有提供多端的算法实现，要么找个算法好的人去研究吃透补全多端实现，要么放弃使用这个办法

3.2、常规二

对密文数据进行分词组合，将分词组合的结果集分别进行加密，然后存储到扩展列，查询时通过key like '%partial%'，这是一个比较划算的实现方法，我们先来分析一下它的实现思路

先对字符进行固定长度的分组，将一个字段拆分为多个，比如说根据4位英文字符（半角），2个中文字符（全角）为一个检索条件，举个例子：

ningyu1使用4个字符为一组的加密方式，第一组ning ，第二组ingy ，第三组ngyu ，第四组gyu1 … 依次类推

如果需要检索所有包含检索条件4个字符的数据比如：ingy ，加密字符后通过 key like “%partial%” 查库

我们都知道加密后长度会增长，增长的这部分长度存储就是我们要花费的额外成本，典型的使用成本来换取速度，密文增长的幅度随着算法不同而不同以DES举例，13800138000加密前占11个字节，加密后的串HE9T75xNx6c5yLmS5l4r6Q==占24个字节，增长是2.18倍，所以一个优秀的算法是多么的重要，能为公司节省不少成本，但是话又说回来算法工程师的工资也不低，所以我也不知道是节省成本还是增加成本，哈哈哈…你们自己算吧

回到主题，这个方法虽然可以实现加密数据的模糊查询，但是对模糊查询的字符长度是有要求的，以我上面举的例子模糊查询字符原文长度必须大于等于4个英文/数字，或者2个汉字，再短的长度不建议支持，因为分词组合会增多从而导致存储的成本增加，反而安全性降低

大家是否都对接过 淘宝、拼多多、JD他们的api，他们对平台订单数据中的用户敏感数据就是加密的同时支持模糊查询，使用就是这个方法，下面我整理了几家电商平台的密文字段检索方案的说明，感兴趣的可以查看下面链接

• 淘宝密文字段检索方案：https://open.taobao.com/docV3.htm?docId=106213&docType=1
• 阿里巴巴文字段检索方案：https://jaq-doc.alibaba.com/docs/doc.htm?treeId=1&articleId=106213&docType=1
• 拼多多密文字段检索方案：https://open.pinduoduo.com/application/document/browse?idStr=3407B605226E77F2
• 京东密文字段检索方案：https://jos.jd.com/commondoc?listId=345

ps. 基本上都是一样的，果然都是互相抄袭，连加密后的数据格式都一致

这个方法优点就是实现起来不算复杂，使用起来也较为简单，算是一个折中的做法，因为会有扩展字段存储成本会有升高，但是可利用数据库索引优化查询速度，推荐使用这个方法

4、超神做法

我们接下来看看优秀的做法，此类做法难度较高，都是从算法层面来考虑，有些甚至会设计一个新算法，虽然已有一些现成的算法参考，但是大多都是半成品无法拿来直接使用，所以还是要有人去深入研究和整合到自己的应用中去

从算法层面思考，甚至会设计一个新算法来支持模糊查找

这个层面大多是专业算法工程师的研究领域，想要设计一个有序的、非不可逆的、密文长度不能增长过快的算法不是一件简单的事情，大致的思路是这样的，使用译码的方式进行加解密，保留密文和原文一样的顺序，从而支持密文模糊匹配，说的比较笼统因为我也不是这方面的专家没有更深一步的研究过，所以我从网上找了一些资料可以参考一下

• 数据库中字符数据的模糊匹配加密方法：https://www.jiamisoft.com/blog/6542-zifushujumohupipeijiamifangfa.html

这里提到的Hill密码处理和模糊匹配加密方法FMES可以重点看看

• 一种基于BloomFilter的改进型加密文本模糊搜索机制研究：http://kzyjc.cnjournals.com/html/2019/1/20190112.htm
• 支持快速查询的数据库如何加密：https://www.jiamisoft.com/blog/5961-kuaisuchaxunshujukujiami.html
• 基于Lucene的云端搜索与密文基础上的模糊查询：https://www.cnblogs.com/arthurqin/p/6307153.html

基于Lucene的思路就跟我们上面介绍的常规做法二类似，对字符进行等长度分词，将分词后的结果集加密后存储，只不过存储的db不一样，一个是关系型数据库，一个是es搜索引擎

云存储中一种支持可验证的模糊查询加密方案http://jeit.ie.ac.cn/fileDZYXXXB/journal/article/dzyxxxb/2017/7/PDF/160971.pdf

5、总结

我们到这里对加密数据的检索方案全部介绍完了，我们首先提到的是网上搜索随处可见的沙雕做法，在这里也讲了不推荐使用这些沙雕做法，尽量使用常规做法，如果公司有专业算法方向人才的话不妨可以考虑基于算法层面的超神做法

总的来说从投入、产出比、及实现、使用成本来算的话常规做法二是非常推荐的

来源：https://ningyu1.github.io/20201230/encrypted-data-fuzzy-query.html

二、加密后的敏感字段还能进行模糊查询吗？该如何实现？

1、前言

有一个问题不知道大家想过没？敏感字段数据是加密存储在数据库的表中，如果需要对这些敏感字段进行模模糊查询，还用原来的通过sql的where从句的like来模糊查询的方式肯定是不行的，那么应该怎么实现呢？这篇文章就来解决这个问题

2、场景分析

假如有类似这样的一个场景：有一个人员管理的功能，人员信息列表的主要字段有姓名、性别、用户账号、手机号码、身份证号码、家庭住址、注册日期等，可以对任意一条数据进行增、删、改、查，其中姓名、身份证号码、手机号码字段要支持模糊查询

简单分析一个场景，可以知道：手机号码、身份证号码、家庭人址字段数据是敏感数据，这些字段的数据是要加密存储在数据库里，在页面上展示的时候需要进行脱敏处理的

如果用户想要查询真实姓名是包含有“张三”的所有人员信息，可以在页面上输入一个关键字，如“张三”，点击开始查询后，这个参数会传递到后台，后台会执行一条sql，如select * from sys_person where real_name like ‘%张三%’，执行结果中包含了所有用户真实姓名包含有“张三”的所有数据记录，如“张三”，“张三丰”等

如果用户要查询手机号码尾号是“0537”的用户，后台执行类似与姓名模糊查询的sql，select * from sys_person where phone like '%0537'，肯定是得不到正确的结果的，因为手机号码字段在数据库中的数据是加密后的结果，而‘0537’是明文。身份证号码、家庭住址等其他敏感字段在模糊查询的时候也都有类似这样的问题，这也是敏感字段模糊查询的痛点，即模糊查询关键字与实际存储的数据不一致

3、实现方案

下面分享几种解决方案：

3.1、第一种，先解密再查询

查询出目标表内所有的数据，在内存中对要模糊查询的敏感字段的加密数据进行解密，然后再遍历解密后的数据，与模糊查询关键字进行比较，筛选出包含有模糊查询关键字的数据行

这种方法是最容易想到的，但有一个比较明显的问题是，模糊查询的过程是在内存中进行的，如果数据量特别大，很容易导致内存溢出，因此不推荐在生产中使用这种方法

3.2、第二种，明文映射表

新建一张映射表，存储敏感字段解密后的数据与目标表主键的映射表，需要模糊查询的时候，先对明文映射表进行模糊查询，得到符合条件的目标数据的主键，再返回来根据主键查询目标表

这种方法，实际上是有点掩耳盗铃的感觉，敏感字段加密存储的字段主要是考虑到安全性，使用明文映射表来存储解密后的敏感字段，实际上相当于敏感字段没有加密存储，与最被要对敏感字段加密的初衷相违背，因此不推荐在生产中使用这种方法

3.3、第三种，数据库层面进行解密查询

后台在执行查询sql时对敏感字段先解密，然后再执行like，以上面的人员管理列表模糊查询为例，即对sql的改造为：select * from sys_person where AES_DECRYPT(phone,'key') like '%0537';

这种方法的优点是，成本比较小，容易实现，但是缺点很明显，该字段无法通过数据库索引来优化查询，另外有一些数据库无法保证数据库的加解密算法与程序的加解密算法一致，可能会导致可以程序中加密，但是无法在数据库中解密的或者可以在数据库加密无法在程序中解密的问题，因此不推荐在生产中使用这种方法

3.4、第四种，分词密文映射表

这种方法是对第二种思路的基础上进行延伸优化，也是主流的方法。新建一张分词密文映射表，在敏感字段数据新增、修改的后，对敏感字段进行分词组合，如“15503770537”的分词组合有“155”、“0377”、“0537”等，再对每个分词进行加密，建立起敏感字段的分词密文与目标数据行主键的关联关系；在处理模糊查询的时候，对模糊查询关键字进行加密，用加密后的模糊查询关键字，对分词密文映射表进行like查询，得到目标数据行的主键，再以目标数据行的主键为条件返回目标表进行精确查询

图片一：分组组合加密前

图片二：分组组合加密后

淘宝、阿里、拼多、京东等大厂对用户敏感数据加密后支持模糊查询都是这样的原理，下面是几个大厂的敏感字段模糊查询方案说明，有兴趣可以了解一下：

（同上）

淘宝密文字段检索方案

• https://open.taobao.com/docV3.htm?docId=106213&docType=1

阿里巴巴文字段检索方案

• https://jaq-doc.alibaba.com/docs/doc.htm?treeId=1&articleId=106213&docType=1

拼多多密文字段检索方案

• https://open.pinduoduo.com/application/document/browse?idStr=3407B605226E77F2

京东密文字段检索方案

• https://jos.jd.com/commondoc?listId=345

这种方法的优点就是原理简单，实现起来也不复杂，但是有一定的局限性，算是一个对性能、业务相折中的一个方案，相比较之下，在能想的方法中，比较推荐这种方法，但是要特别注意的是，对模糊查询的关键字的长度，要在业务层面进行限制；以手机号为例，可以要求对模糊查询的关键字是四位或者是五位，具体可以再根据具体的场景进行详细划分

为什么要增加这样的限制呢？因为明文加密后长度为变长，有额外的存储成本和查询性能成本，分词组合越多，需要的存储空间以及所消耗的查询性能成本也就更大，并且分词越短，被硬破解的可能性也就越大，也会在一定程度上导致安全性降低

4、环境配置

• jdk版本:1.8开发工具：Intellij iDEA 2020.1
• springboot:2.3.9.RELEASE
• mybatis-spring-boot-starter：2.1.4

5、依赖配置

示例主要用到了SpringAop，加密是对称加密，用到了hutool工具包里的加密解密工具类，也可以使用自己封装的加密解密工具类

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>
<dependency>
    <groupId>cn.hutool</groupId>
    <artifactId>hutool-all</artifactId>
    <version>5.3.3</version>
</dependency>

6、代码实现

6.1、新建分词密文映射表

如果是多个模糊查询的字段，可以共用在一张分词密文映射表中扩展多个字段，以示例中的人员管理功能为例，新建sys_person_phone_encrypt表（人员的手机号码分词密文映射表），用于存储人员id与分词组合密文的映射关系

create table if not exists sys_person_phone_encrypt
(
   id bigint auto_increment comment '主键' primary key,
   person_id int not null comment '关联人员信息表主键',
   phone_key varchar(500) not null comment '手机号码分词密文'
)
comment '人员的手机号码分词密文映射表';

6.2、敏感字段数据在保存入库的时候，对敏感字段进行分词组合并加密码，存储在分词密文映射表

在注册人员信息的时候，先取出通过AOP进行加密过的手机号码进行解密；手机号码解密之后，对手机号码按照连续四位进行分词组合，并对每一个手机号码的分词进行加密，最后把所有的加密后手机号码分词拼接成一个字符串，与人员id一起保存到人员的手机号码分词密文映射表

public Person registe(Person person) {
    this.personDao.insert(person);
    String phone = this.decrypt(person.getPhoneNumber());
    String phoneKeywords = this.phoneKeywords(phone);
    this.personDao.insertPhoneKeyworkds(person.getId(),phoneKeywords);
    return person;
}
private String phoneKeywords(String phone) {
    String keywords = this.keywords(phone, 4);
    System.out.println(keywords.length());
    return keywords;
}
 
// 分词组合加密
private String keywords(String word, int len) {
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < word.length(); i++) {
        int start = i;
        int end = i + len;
        String sub1 = word.substring(start, end);
        sb.append(this.encrypt(sub1));
        if (end == word.length()) {
            break;
        }
    }
    return sb.toString();
}
public String encrypt(String val) {
    // 这里特别注意一下，对称加密是根据密钥进行加密和解密的，加密和解密的密钥是相同的，一旦泄漏，就无秘密可言，
    // “fanfu-csdn”就是我自定义的密钥，这里仅作演示使用，实际业务中，这个密钥要以安全的方式存储；
    byte[] key = SecureUtil.generateKey(SymmetricAlgorithm.DES.getValue(), "fanfu-csdn".getBytes()).getEncoded();
    SymmetricCrypto aes = new SymmetricCrypto(SymmetricAlgorithm.DES, key);
    String encryptValue = aes.encryptBase64(val);
    return encryptValue;
}
public String decrypt(String val) {
    // 这里特别注意一下，对称加密是根据密钥进行加密和解密的，加密和解密的密钥是相同的，一旦泄漏，就无秘密可言，
    // “fanfu-csdn”就是我自定义的密钥，这里仅作演示使用，实际业务中，这个密钥要以安全的方式存储；
    byte[] key = SecureUtil.generateKey(SymmetricAlgorithm.DES.getValue(), "fanfu-csdn".getBytes()).getEncoded();
    SymmetricCrypto aes = new SymmetricCrypto(SymmetricAlgorithm.DES, key);
    String encryptValue = aes.decryptStr(val);
    return encryptValue;
}

6.3、模糊查询的时候，对模糊查询关键字进行加密，以加密后的关键字密文为查询条件，查询密文映射表，得到目标数据行的id，再以目标数据行id为查询条件，查询目标数据表

根据手机号码的四位进行模糊查询的时候，以加密后模糊查询的关键字为条件，查询sys_person_phone_encrypt表（人员的手机号码分词密文映射表），得到人员信息id；再以人员信息id，查询人员信息表

public List<Person> getPersonList(String phoneVal) {
    if (phoneVal != null) {
       return this.personDao.queryByPhoneEncrypt(this.encrypt(phoneVal));
    }
    return this.personDao.queryList(phoneVal);
}
<select id="queryByPhoneEncrypt" resultMap="personMap">
    select * from sys_person where id in 
    (select person_id from sys_person_phone_encrypt
     where phone_key like concat('%',#{phoneVal},'%'))
</select>

示例完整代码：

https://gitcode.net/fox9916/fanfu-web.git

来源：blog.csdn.net/fox9916/article/details/129997442

三、加密的手机号，如何模糊查询？

1、前言

我们都知道，在做系统设计时，考虑到系统的安全性，需要对用户的一些个人隐私信息，比如：登录密码、身份证号、银行卡号、手机号等，做加密处理，防止用户的个人信息被泄露

很早之前，CSDN遭遇了SQL注入，导致了600多万条明文保存的用户信息被泄

因此，我们在做系统设计的时候，要考虑要把用户的隐私信息加密保存

常见的对称加密算法有 AES、SM4、ChaCha20、3DES、DES、Blowfish、IDEA、RC5、RC6、Camellia等

目前国际主流的对称加密算法是AES，国内主推的则是SM4

无论是用哪种算法，加密前的字符串，和加密后的字符串，差别还是比较大的

比如加密前的字符串：测试加密，使用密钥：123，生成加密后的字符串为：U2FsdGVkX1+q7g9npbydGL1HXzaZZ6uYYtXyug83jHA=

如何对加密后的字符串做模糊查询呢

比如：假设查询测试关键字，加密后的字符串是：U2FsdGVkX19eCv+xt2WkQb5auYo0ckyw

上面生成的两个加密字符串差异看起来比较大，根本没办法直接通过SQL语句中的like关键字模糊查询

那我们该怎么实现加密的手机号的模糊查询功能呢

2、一次加载到内存

实现这个功能，我们第一个想到的办法可能是：把个人隐私数据一次性加载到内存中缓存起来，然后在内存中先解密，然后在代码中实现模糊搜索的功能

这样做的好处是：实现起来比较简单，成本非常低

但带来的问题是：如果个人隐私数据非常多的话，应用服务器的内存不一定够用，可能会出现OOM问题

还有另外一个问题是：数据一致性问题

如果用户修改了手机号，数据库更新成功了，需要同步更新内存中的缓存，否则用户查询的结果可能会跟实际情况不一致

比如：数据库更新成功了，内存中的缓存更新失败了

或者你的应用，部署了多个服务器节点，有一部分内存缓存更新成功了，另外一部分刚好在重启，导致更新失败了

该方案不仅可能会导致应用服务器出现OOM问题，也可能会导致系统的复杂度提升许多，总体来说，有点得不偿失

3、使用数据库函数

既然数据库中保存的是加密后的字符串，还有一种方案是使用数据库的函数解密

我们可以使用MySQL的DES_ENCRYPT函数加密，使用DES_DECRYPT函数解密：

SELECT 
DES_DECRYPT('U2FsdGVkX1+q7g9npbydGL1HXzaZZ6uYYtXyug83jHA=', '123'); 

应用系统中所有的用户隐私信息的加解密都在MySQL层实现，不存在加解密不一致的情况

该方案中保存数据时，只对单个用户的数据进行操作，数据量比较小，性能还好

但是模糊查询数据时，每一次都需要通过DES_DECRYPT函数，把数据库中用户某个隐私信息字段的所有数据都解密了，然后再通过解密后的数据，做模糊查询

如果该字段的数据量非常大，这样每次查询的性能会非常差

4、 分段保存

我们可以将一个完整的字符串，拆分成多个小的字符串

以手机号为例：18200256007，按每3位为一组，进行拆分，拆分后的字符串为：182,820,200,002,025,256,560,600,007，这9组数据

然后创建一张表：

CREATE TABLE `encrypt_value_mapping` (
  `id` bigint NOT NULL COMMENT '系统编号',
  `ref_id` bigint NOT NULL COMMENT '关联系统编号',
  `encrypt_value` varchar(255) NOT NULL COMMENT '加密后的字符串'
) ENGINE=InnoDB  CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='分段加密映射表'

这张表有三个字段：

id：系统编号

• List item
• ref_id：主业务表的系统编号，比如用户表的系统编号
• encrypt_value：拆分后的加密字符串

用户在写入手机号的时候，同步把拆分之后的手机号分组数据，也一起写入，可以保证在同一个事务当中，保证数据的一致性

如果要模糊查询手机号，可以直接通过encrypt_value_mapping的encrypt_value模糊查询出用户表的ref_id，再通过ref_id查询用户信息

具体sql如下：

select s2.id,s2.name,s2.phone 
from encrypt_value_mapping s1
inner join `user` s2 on s1.ref_id=s2.id
where s1.encrypt_value = 'U2FsdGVkX19Se8cEpSLVGTkLw/yiNhcB'
limit 0,20;

这样就能轻松地通过模糊查询，搜索出我们想要的手机号了

注意这里的encrypt_value用的等于号，由于是等值查询，效率比较高

注意：这里通过sql语句查询出来的手机号是加密的，在接口返回给前端之前，需要在代码中统一做解密处理

为了安全性，还可以将加密后的明文密码，用*号增加一些干扰项，防止手机号被泄露，最后展示给用户的内容，可以显示成这样的：182***07

5、其他的模糊查询

如果除了用户手机号，还有其他的用户隐私字段需要模糊查询的场景，该怎么办

我们可以将encrypt_value_mapping表扩展一下，增加一个type字段

该字段表示数据的类型，比如：1.手机号 2.身份证 3.银行卡号等

这样如果有身份证和银行卡号模块查询的业务场景，我们可以通过type字段做区分，也可以使用这套方案，将数据写入到encrypt_value_mapping表，最后根据不同的type查询出不同的分组数据

如果业务表中的数据量少，这套方案是可以满足需求的

但如果业务表中的数据量很大，一个手机号就需要保存9条数据，一个身份证或者银行卡号也需要保存很多条数据，这样会导致encrypt_value_mapping表的数据急剧增加，可能会导致这张表非常大

最后的后果是非常影响查询性能

那么，这种情况该怎么办呢

6、增加模糊查询字段

如果数据量多的情况下，将所有用户隐私信息字段，分组之后，都集中到一张表中，确实非常影响查询的性能

那么，该如何优化呢

答：我们可以增加模糊查询字段

还是以手机模糊查询为例

我们可以在用户表中，在手机号旁边，增加一个encrypt_phone字段

CREATE TABLE `user` (
  `id` int NOT NULL,
  `code` varchar(20)  NOT NULL,
  `age` int NOT NULL DEFAULT '0',
  `name` varchar(30) NOT NULL,
  `height` int NOT NULL DEFAULT '0',
  `address` varchar(30)  DEFAULT NULL,
  `phone` varchar(11) DEFAULT NULL,
  `encrypt_phone` varchar(255)  DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='用户表'

然后我们在保存数据的时候，将分组之后的数据拼接起来

还是以手机号为例：

18200256007，按每3位为一组，进行拆分，拆分后的字符串为：182,820,200,002,025,256,560,600,007，这9组数据

分组之后，加密之后，用逗号分割之后拼接成这样的数据：,U2FsdGVkX19Se8cEpSLVGTkLw/yiNhcB,U2FsdGVkX1+qysCDyVMm/aYXMRpCEmBD,U2FsdGVkX19oXuv8m4ZAjz+AGhfXlsQk,U2FsdGVkX19VFs60R26BLFzv5nDZX40U,U2FsdGVkX19XPO0by9pVw4GKnGI3Z5Zs,U2FsdGVkX1/FIIaYpHlIlrngIYEnuwlM,U2FsdGVkX19s6WTtqngdAM9sgo5xKvld,U2FsdGVkX19PmLyjtuOpsMYKe2pmf+XW,U2FsdGVkX1+cJ/qussMgdPQq3WGdp16Q

以后可以直接通过sql模糊查询字段encrypt_phone了：

select id,name,phone
from user where encrypt_phone like '%U2FsdGVkX19Se8cEpSLVGTkLw/yiNhcB%'
limit 0,20;

注意这里的encrypt_value用like

这里为什么要用逗号分割呢

答：是为了防止直接字符串拼接，在极端情况下，两个分组的数据，原本都不满足模糊搜索条件，但拼接在一起，却有一部分满足条件的情况发生

当然你也可以根据实际情况，将逗号改成其他的特殊字符

此外，其他的用户隐私字段，如果要实现模糊查询功能，也可以使用类似的方案

最后说一句，虽说本文介绍了多种加密手机号实现模糊查询功能的方案，但我们要根据实际业务场景来选择，没有最好的方案，只有最合适的