如果是后台开发场景，想必大家都实现了列表查询的界面。当然，有些查询条件很简单，一个SQL就搞定了，但有些查询条件极其复杂。再加上库表各种不当设计，查询界面特别难写，然后就不用说要加班了(不知道大家有没有这种感觉~) 让我们从下面的例子开始。这是一个购物网站的搜索条件。如果您要实现这样一个搜索接口，您将如何实现它？(当然你说借助搜索引擎，比如Elasticsearch，完全可以实现。 但是我在这里想说的是，如果你想自己实现呢？从上图可以看出，搜索分为六个类别，每个类别又分为子类别。 中间是各个类别的条件交集，每个子类别中有单项选择、多项选择、自主设置。最后输出合格的结果集。 好了，既然需求明确了，那就开始实现吧。 1.是小啊，他是写SQL的“专家”。 a很自信的说，“不就是一个查询接口吗？条件很多，但是以我丰富的SQL经验，这个对我来说还是比较难的。 于是我写了下面的代码(这里以MYSQL为例):代码在测试环境下运行，结果好像是吻合的，所以我提前做好了发送的准备。 这一推进，问题就开始暴露了。 为了在网络环境下尽可能真实，数据量自然要比测试大很多。 所以这么复杂的SQL，其执行效率可想而知。 测试同学果断打回了小a的代码。 2实现总结小啊失败的教训，小B开始优化SQL。首先，它通过explain关键字分析SQL的性能，并向索引位置添加索引。 同时将一个复杂的SQL拆分成多个SQL，计算结果在程序内存中进行计算。 伪代码如下:这个方案在性能上明显优于第一个方案，但是产品经理在功能接受过程中还是觉得查询速度不够快。 b自己也知道每一次查询都会重复到数据库，一些历史原因和一些条件无法进行单表查询，所以查询的等待时间是不可避免的。 实现小C从上面的方案看优化的空间。 他发现小B思维没有问题，把复杂的条件拆分，计算出每个子维度的结果集，最后把所有子结果集汇总合并，得到最终想要的结果。 于是他突发奇想，要不要提前缓存每个子维度的结果集，这样查询的时候就可以直接得到想要的子集，而不用每次都去查数据库计算。 在这里，小C使用Redis存储缓存数据。使用它的主要原因是它提供了多种数据结构，在Redis中很容易执行集合的交和并。 具体方案，如图:对于这里的每一个条件，预先将计算出的结果集ID存储在对应的key中，并设置所选择的数据结构。 查询包括:子类单选:根据条件键直接获取对应的结果集；多个子类:根据多个条件键进行union运算，得到对应的结果集；最后:对得到的所有子类结果集进行交集运算，得到最终结果；这其实就是所谓的倒排索引。 这里会发现遗漏了一个价格条件。 从需求可以看出，价格条件是一个区间，无限大。 所以上面提到的穷举条件的键值法是做不到的。 这里我们用Redis的另一种数据结构来实现，排序集:所有商品加入一个以Key为价格的有序集，值为商品ID，每个值对应的分值为商品价格的值。 这样在Redis的有序集合中，通过ZRANGEBYSCORE命令就可以根据得分(价格)区间得到相应的结果集。 至此，第三种方案的优化已经完成，通过缓存的方式将数据查询和计算分离。 在每次搜索中，你只需要简单地搜索Redis几次就可以得到结果。 查询速度符合受理要求。 分页到这里，你可能发现了一个严重的功能缺陷。列表查询怎么可能没有分页？ 是的，我们马上来看看Redis是如何实现分页的。 分页主要涉及排序。为简单起见，以创建时间为例。 如图:图中蓝色部分是以创建时间为分值的商品有序集，蓝色部分下方的结果集是条件计算的结果。通过ZINTERSTORE命令，结果集的权重为0，乘积时间结果为1，交集得到的结果集被赋予一个新的有序集，带有创建时间分数。 对新结果集的操作可以得到分页所需的全部数据:总页数为:ZCOUNT命令当前页面内容:ZRANGE命令如果是逆序排列:ZREVRANGE命令数据升级有两种方法可以升级索引数据。 一种是通过修改商品数据立即触发升级操作，另一种是通过定时脚本批量升级。 这里需要注意的是，关于索引内容的升级，如果密钥被暴力删除，会重新设置密钥。 因为Redis中的两个操作不会是原子的，所以它们之间可能会有差距。建议仅删除集合中的无效元素，并添加新元素。 优化performance Redis是一个内存级的操作，所以一个查询会很快。 但是，如果我们的实现中存在重复的Redis操作，Redis的重复连接时间可能是不必要的时间消耗。 使用MULTI命令启动一个事务，将Redis的重复操作放在一个事务中，最后通过exec进行原子执行(注意:这里所谓的事务只是在一个连接中进行多个操作，如果执行失败，不会回滚) 总之，这只是一个使用Redis优化查询搜索的简单演示。与现有的开源搜索引擎相比，它更轻便，学习成本更低。 其次，它的思路和开源搜索引擎类似。如果加上单词解析，可以实现类似的全文搜索功能。