（1）概述：
    上次讲到，在这个场景里SQL中包含where，order by和limit语句，实际场景中，往往where和order by是没法都用到索引的，今天分析第二个问题，就是在where 和 order by出现 索引设计冲突，到底是针对where去设计索引还是针对 order by设计索引，到底让where用上索引，还是order by用上索引？
    其实这个问题的本质就是说，是要让where语句先基于联合索引进行一个筛选，筛选出来一部分用户指定的数据，接着再把数据加载到内存或者是基于临时磁盘文件去进行指定条件的排序， 最后用limit语句拿到一页的数据？ 还是说让order by语句按照你的索引的顺序去找，找的过程中基于where里的条件筛选出来指定的数据，然后再根据limit语句拿出来一条数据。


    说实话，一般这种时候往往都是让where条件去使用索引快速筛选出一部分指定的数据，接着再进行排序，最后针对排序后的数据拿出来一页数据。因为基于索引进行where筛选往往可以 最快速度筛选出需要的少部分数据，如果筛选出来的数据量不是太大的话，后续排序和分页的成本往往不会太大。
    好，假设我们针对where条件去设计索引，此时就要考虑，用户在搜索潜在好友的时候，一般会用上那些条件？到底要把那些字段包含到索引里去？到底在联合索引里，字段的顺序要如何 排列呢？
    首先应该在联合索引里包含省份，城市，性别，这三个索引，因为这三个字段都是在搜索集里几乎必定包含的三个字段，假设要搜索潜在好友，必定会搜索跟你同一个地方的，然后搜索 某个性别的其他用户，这几个条件在APP里完全可以做成必选项，用户也必定指定。

    1. 但是此时之前不是说，基数太低的字段最好别放到索引里？省份，城市，性别都是基数非常小的几个字段，为什么要放到索引里去？


    假设因为省份，城市和性别几个字段的基数太小，此时不把他们包含到联合索引里去，实际查询的时候都要基于这几个字段去搜索，此时就只能把这几个字段放到where条件的最后，那最后 每次查询都必须要先用联合索引查询出来一部分数据，接着数据加载到内存里去，再根据where条件最后的省份，城市和性别几个字段进行过滤，每次查询都需要这个步骤。与其如此，还不如把省份， 城市和性别三个字段，放在联合索引的最左侧，这个跟其他字段组成联合索引后，让大部分的查询都可以直接通过索引树把where条件指定的数据筛选出来。