1，现状
（1）概述：目前网站列表页面的过滤条件是：1 级分类、最新/人气，我们采用的是 redis 缓存 id 和时间，同时配合页面静态缓存。 （2）具体：建立了多个 redis 有序集 (Sorted set)，键分别是“latest”，“hot”，“latest:#{category_id} ”，“hot:#{category_id} ”。查询是通过 redis 的 ZRANGE/ZREVRANGE 方法实现分页和时间排序，获取 id 之后再从 mongodb 中查询具体信息。
2，新需求遇到的问题
（1）概述：丰富过滤条件，如图：
（2）解决：因为是多条件组合查询 + 翻页，所以不能使用 redis 做缓存。想到给 mongodb 建立索引，通过分析得到为了适应各个条件组合需要建立约 30 个索引 (排序也要建立索引)。这样有 2 个问题：一是会增大索引大小，占用内存，目前索引已经 10G；二是索引多了，影响写入速度。
所以，请教大家，对于这种多组合的查询列表页，大家一般如何缓存？
在考虑一种“笨”方法： 做定时任务，每 4 小时从数据库中读取所有组合条件的查询结果的 id（限制最多返回的记录数），存储在 redis 中。避免每次都直接从数据库中读取，避免建立过多的索引。
大家有遇到过这种需求吗，一般怎么处理？
#3 楼 @kenshin54 是走搜索引擎吧，这个也考虑过，不过我们目前使用的是 sphinx，遇到 1 个问题，有些属性当初没有放在索引的建立中，如果这么做的话，需要给所有数据重新建立一次索引。路是行的通，就是感觉不方便。其次，我看一些网站做的这种页面，也没有走搜索，速度也很快。
#8 楼 @helloqidi sphinx 的索引速度非常快的啊，这种可以组合的搜索条件，用搜索引擎做我觉得比较方便，而且 solr 和 elasticsearch 的实时索引很方便，不需要重建整个索引，elasticsearch 的 dynamic mapping 也可以动态扩展索引文档的结构。只是索引速度不如 sphinx，运行时需要比 sphinx 多点内存，当然主要看数据量和具体用法。用搜索引擎，算是个比较方便，性能速度也不错的方案。当然其他方式也能实现。
#14 楼 @helloqidi 命中率太低了，绝大多数用户都是看前面一两页的，后面的缓存了也没有意义，重点是要让直接查询够快，这才是正解。
楼上所说的用搜索引擎来实现也是一个方法