标签筛选优化方案

Question

如图：

这样的标签筛选，如果直接从数据库里拿，sql就可以直接搞定，但是不太理想，假如每个标签的房源都有一个 Redis 的列表，比如：
区域(朝阳区)的列表 - 1,23,456,1211,983·····
面积(80平米)的列表 - 21,243,1456,1211,983,442·····
这样的话，有什么好的优化方案

我想了两个方案：
① 每个标签的列表，30个一组，
区域(朝阳区)的列表 - 组1 - 1,23,456,1211,983·····
区域(朝阳区)的列表 - 组2 - ·····
面积(80平米)的列表 - 组1 - 21,243,1456,1211,983,442·····
面积(80平米)的列表 - 组2 - ·····
假如每页显示10条数据，用户选择的是朝阳区80平米的房子，我就拿上面的地区列表的组1和面积的组1取交集，如果结果够10条，则满足需求，如果不够10条，就再取第二组的信息，直到显示10条信息
但是这样存在一个很大的问题：越往后分页，计算量越大，数据量再一大，效果肯定不理想
而且这些要想得出总条数也很困难(虽然现在一般都不显示总记录了)，即便是标签不分组的情况，假如朝阳区的列表有1000W个，那这个取交集的时候，一下扔到内存，似乎也比较尴尬

② 用sql+定时任务，把每种可能性的结果存在Redis，但是标签很多，就会有很多sql，感觉有点得不偿失

请教诸位，这类问题，有什么好的解决方案吗？
谢谢诸位

Answer 1

我觉得sql方式就挺好啊， 把房源按标签分类都打上标签(一种类型一个字段)，直接一个sql(select * where a=x or b=x or c=x)就出来了。 索引建好了，也基本不会有性能问题，如果还是担心，那就redis缓存一下结果啊，乘一下也就一两百种结果。

Answer 2

对于这种需求，不建议直接使用sql进行查询。
一般会使用“全文搜索引擎”实现。PHP有sphinx，可以利用sphinx实现一个搜索中间层服务（中间件搜索服务），业务调用这个中间层，从而实现快速检索。