主要观点总结
本文主要讨论了加密数据的模糊查询实现思路，包括沙雕做法、常规做法和超神做法。并对不同做法进行了详细的分析和比较，最后推荐了常规做法二作为较为优秀的解决方案。
关键观点总结
关键观点1: 加密数据模糊查询的问题和挑战
数据加密后，需要平衡数据的安全性和查询效率。可逆加密可能降低安全性，而不可逆加密则不利于模糊查询。需要找到一种平衡两者之间的方法。
关键观点2: 沙雕做法的缺点
沙雕做法包括将数据全部加载到内存中进行解密和创建明文映射表。这些方法在处理大量数据时可能导致内存溢出，并且降低数据的安全性。
关键观点3: 常规做法的优点和缺点
常规做法在数据库中实现加密算法函数，通过like语句进行模糊查询。这种方法满足数据安全性要求，查询效率也较高。但是可能无法利用数据库索引优化查询，且可能需要程序与数据库之间的算法一致性。
关键观点4: 推荐的做法
推荐的做法是对密文数据进行分词组合，将结果集加密后存储到扩展列，通过key like '%partial%'进行查询。这种方法较为划算，可以利用数据库索引优化查询速度，但需要额外的存储成本。
关键观点5: 超神做法的挑战
超神做法从算法层面考虑，设计新的算法来支持模糊查找。这种方法难度较大，需要专业算法工程师深入研究，但可以有效提高数据的安全性和查询效率。
正文
将密文数据映射一份明文映射表，俗称tag表，然后模糊查询tag来关联密文数据
我们先来看看第一个做法，将所有数据加载到内存中进行解密，这个如果数据量小的话可以使用这个方式来做，这样做既简单又实惠，如果数据量大的话那就是灾难，我们来大致算一下。
一个英文字母(不分大小写)占一个字节的空间，一个中文汉字占两个字节的空间，用DES来举例，13800138000加密后的串HE9T75xNx6c5yLmS5l4r6Q==占24个字节。
轻则上百兆，重则上千兆，这样分分钟给应用程序整成Out of memory，这样做如果数据少只有几百、几千、几万条时是完全可以这样做的，但是数据量大就强烈不建议了。
我们再来看第二个做法，将密文数据映射一份明文映射表，然后模糊查询映射表来关联密文数据，what？？？！！！那我们为什么要对数据加密呢，直接不加密不是更好么！
我们既然对数据加密肯定是有安全诉求才会这样做，增加一个明文的映射表就违背了安全诉求，这样做既不安全也不方便完全是脱裤子放x，多此一举，强且不推荐。
我们接下来看看常规的做法，也是最广泛使用的方法，此类方法及满足的数据安全性，又对查询友好。
在数据库实现加密算法函数，在模糊查询的时候使用decode(key) like '%partial%
