（1）前序：
    陌生人社交APP核心主旨，就是进入APP的时候，录入你的一系列个人信息，接着APP会通过一定的算法推荐一些可能适合你的人给你进行线上交友，当然也有可能是你自己通过一定的条件筛选 好友，那我们来思考下，在筛选的时候，是针对社交APP的那个表进行查询的？

    （2）用户信息表：
    针对用户信息，有一个user_info这么一个表。这个表里包含你的 地区，性别，身高，体重，兴趣爱好，还有照片，当然还有最后一次在线时间。另外如果支持交友过程中让其他人进行评价，那 还会有个综合评分。
    针对用户表的搜索，可不仅仅是筛选那么简单，除了SQL select xx from user_info where xx=xx 有系列的条件外，APP肯定得支持分页把？所以肯定还得跟上limit xx,xx 的分页语句。 同时很关键的一点是，搜索的时候，肯定不是随便胡乱排序的，总得根据一定的规则对筛选出来的结果进行一个排序，把最符合你的条件和期望的用户排列在最上面才可以。
    那么最终SQL语句可能是类似于： select xx from user_info where xx=xx order by xx limit xx,xx

    所以这里有个难题，我们知道，where条件里必须使用联合索引里最左侧开始的连续多个字段进行筛选，然后排序的时候也必须是用联合索引里的最左侧开始的多个连续字段进行排序。那么问题 来了，假设SQL 按照年龄范围筛选，同时需要按照用户的评分进行排序，类似SQL select xx from user_info where age between 20 and 25 order by score ,这就有问题了。假设就一个联合 索引，age在最左侧，那where是可以用上索引的，但是排序是基于score字段，那就用不到索引了。假设针对age和score分别设计了两个索引，但是SQL里假设基于age索引进行了筛选，是没法利用另外 一个score索引进行排序的。

    （3）总结：
    所以，针对这个场景，往往类似这种SQL里，where 和 order by 排序 大部分情况下是没法都用到索引的！！！
    除此外这个业务场景下的查询语句还有那些索引设计上的难点？

    知识点：age和score分别建索引，然后age进行范围查询，score进行排序，这种情况走不能走索引，原因 age 区间筛选之后score的值本身就无需了，所以排序会使用临时内存表。 如果是 age+score 的联合索引，where age between 20 and 25 order by age，score 这样索引就用上了。