在此之前，我做过不少ToC的项目，在ToC的应用场景中，业务一般都是比较简单，基本上没有多少复杂的查询（基本上，只要建立用户ID为索引，就能够大大提升查询效率了。）这两年，也逐渐接触到一些ToB的业务，发现ToB的业务，真的是比ToC的要复杂一些。举个简单的例子，ToB应用中，最痛苦的事情就是组织架构，原本查询一个人的数据，可能变成查询一个小组，一个部门，甚至是一个分公司的数据。
不仅如此，由于不同职级的员工的查询权限可能不一样。查询条件比ToC场景中复杂得多，所以有时候一张表，会建立好多个不同的索引。后时候我们就会发现，怎么查询莫名其妙就变得很慢了。按道理说，如果命中了我们想要的索引，应该很快才对。
于是，我们就对Sql语句进行分析，发现Mysql使用的是另外一个索引，但是在这个业务下，使用另外一个索引会得到更好的结果，为什么Mysql会选错索引呢？很显然，存储很难会去理解业务的实际情况，Mysql也需要一定的算法才能评估出索引的优劣，Mysql是这样进行评分的。
Mysql对索引的评分的首要原则，就是索引的差异度最大，举个例子，假如是一个小学生信息查询系统，我们以出生日期建立索引，那么大概就有*7个不同的值，假如我们以学生的性别作为索引，那么基本上就只有2个不同的值了，假如一个查询条件同时包含出生日期跟性别，那么Mysql必然优先选基数更大的作为索引，也就是出生日期作为索引。
那但是，Mysql实际上并不理解什么是出生日期，什么是性别，他们是判断哪一个基数更大的呢？非常简单，把索引扫一遍不就知道结果了么？我们只要在索引树上扫一遍，就能够知道不同的Key有多少个。但是，假如我们的数据越来越多，每次都把所有的索引树都扫描一遍并不现实。基于大多数的互联网应用都是读多写少的，Mysql会把索引的评分记录一段时间，但是，每次触发重新评估的时候，仍要花费不少的时间。
Mysql采用抽样调查的方式，随机从各个索引树上面取一定的页数，通过统计这些页数对索引进行评估。现在回到我们现实的开发中，不知道你有没有遇到过这样的问题，一些异常状态占总数量非常少，例如退货退款的订单只占总订单的少数，但是你使用Mysql查询的时候却很命中这个索引。就是因为在Mysql评估分数的时候，大多数时候都会觉得这个索引上面不同数据量很少，所以打了低分。所以，如果你有这种特殊的业务场景，最好进行指定索引。
好了，今天我们简单介绍了mysql的索引选择，不知道对你是否有所启发，欢迎大家