数据库加密可以保障数据的安全，但是也会带来很多的问题，其中有一个比较关键的就是数据的模糊查询的问题。

当我们通过加密后把密文存到数据库中的时候，再通过明文进行模糊查询是不生效的。

比如Hollis加密后的内容是363164846D8200899E314897E64A7420，那么当我想用Ho来做模糊查询时候，那么他的密文是71AAFD38484F3160708C6A6D2D5F736B，这两个密文可以说是没有任何关系的，所以，是无法直接做模糊查询的。那么如何解决这个问题呢？

一种比较常见的方法，就是把要查询的表中的所有符合条件的数据，都加载到应用内存中，在内存中逐个解密，然后再做模糊匹配。

这个方案的优点就是实现简单，缺点也很明显，需要把所有数据都加载到内存中，容易导致OOM。不推荐!

还有人提出过说单独建一张表，其中保存明文和目标表之间的映射，需要模糊查询的时候先去明文映射表中查到主键，然后再去目标表查询数据。

但是这个方案基本上是属于自欺欺人，因为一旦数据被拖库，还是会丢。不推荐

加密的时候如果用了函数的话，解密的时候我们也可以借助函数来做解密，同时做模糊查询，比如加密时使用了AES_ENCRYPT算法：

-- 加密数据INSERT INTO user_data (username, credit_card) VALUES ('Hollis', AES_ENCRYPT('1234-5678-9012-3456', 'hollis_secret_key'));

那么在做模糊查询的时候就可以这样做：

SELECT * FROM user_data WHERE AES_DECRYPT(credit_card, 'hollis_secret_key') like 'Hol%';

这样也就能实现一个模糊查询的效果了，但是这个方案有个缺点，就是无法用到索引，不是因为用like，而是因为我们在字段上用了函数，索引就会失效。

这个方案适合于表中数据量不大，或者查询条件中还有其他查询字段可以走索引的情况。

还有一个比较简单的做法，也是很多大厂在用的方案。

那就是对明文进行分词，然后分别加密后存储到数据库中，比如Hollis这个需要加密的字符串，我们就可以把他拆成Ho 、Holl、llis等这几个字符串，然后分别对他们进行加密，并保存到数据库中。

这样当我们使用Ho 、Holl、llis 进行查询的时候，就可以对明文加密后去数据库中匹配了。

这个方案的缺点也比较明显，第一个就是需要冗余很多字段，第二个就是不够灵活，如果我按照Holli来查询的话就不支持了。

这个方案本质就是一种比较典型的用空间换时间的做法，理论上只要你愿意，可以把所有的可能的查询都做冗余。