前言：

 数据库作为存储用户信息的地方，如何保护好数据库的安全性一直都是开发者所追求的终极目标。

目前最常见的数据库加密方法就是：拒绝明文存储信息。比如我们可以存储加密后的信息，把解密放到代码逻辑中去做。但是这种存储加密信息的方式也会存在问题。

目录

前言：

问题： 

1:在代码中进行解密

2. 建立映射表

3.明文分词

总结：

---

问题： 

当我们信息加密存储到数据库后，其实就没有办法对这段数据进行模糊查询了。

比如：我们使用MD5加密算法加密字符串“1234567”之后，把加密得到的字符串“FCEA920F7412B5DA7BE0CF42B8C93759”存储在数据库中

此时如果我们想进行模糊查询，输入“1234”的时候，加密得到的字符串是：“81DC9BDB52D04DC20036DBD8313ED055”。

这两串毫不相干的加密后字符串肉眼可见的无法进行匹配。

那我们对敏感信息进行加密之后，要如何做用户的模糊查询呢？

---

 

1:在代码中进行解密

我们把加密信息提取到代码中，在代码中进行解密，然后再做模糊匹配。

虽然他的逻辑很简答，但是他的问题也很明显：

• 把数据加载到代码中，容易出现OOM异常。
• 数据量过大的时候，及其占用IO资源。
• 加密方式为可逆加密，因此仍然存在安全性问题。

2. 建立映射表

这种方式的思想是：建立映射表，查询的时候先根据数据库暴漏的真实信息去做查询，根据映射表中的结果去查询加密信息。

这种方式我都不知道是不是我理解错了，通过暴漏信息的方式来模糊查询。感觉使用的场景太少了。

我目前只能想到：比如我们要根据手机模糊查询用户的信息，而用户的信息我们又不能全部暴漏，所以选项暴漏电话来做模糊查询。如下图所示

3.明文分词

既然我们没有办法根据“ABC” 模糊查询“ABCDE”，那么我们为什么提前就存储好拆分字段的加密结果呢？

比如：

那么我们可以冗余一些字段来存储当前字段拆分后的部分字段的加密结果。

这样我们就可以进行模糊查询了，如果不想模糊查询，还可以把冗余拆分字段变成字符串合并在一起：

这样的话也可以有效减少冗余字段。

而很多的大公司也在用这种方式来进行加密字段的模糊查询，例如阿里巴巴：

开放平台-文档中心 (taobao.com)https://open.taobao.com/docV3.htm?docId=106213&docType=1#s0

阿里公开的这篇文章中的其实也就是拆分明文字符串的思想。

总结：

数据库字段加密是保护敏感信息安全的有效手段，然而，它也带来了一些挑战，其中之一就是限制了常规的模糊查询操作。加密后的数据无法直接进行模糊匹配，从而影响了对加密字段的模糊查询功能。在解决这个问题的过程中，我们要尽力确保在保护数据安全的同时，尽可能地满足查询需求，为数据库安全与灵活性之间的平衡找到最佳解决方案。

如果我的内容对你有帮助，请点赞，评论，收藏。创作不易，大家的支持就是我坚持下去的动力！