优化器的逻辑
选择索引是优化器的工作。
而优化器选择索引的目的，是找到一个最优的执行方案，并用最小的代码去执行语句。在数据库里面，扫描行数是影响执行代价的因素之一。扫描的行数越少，意味着访问磁盘数据的次数越少，消耗的 CPU 资源越少。
那么，扫描行数是怎么判断的？
MySQL在真正执行开始执行语句之前，并不能精确地知道满足这个条件的记录有多少条，而只能根据统计信息来估算记录数。
索引选择异常和处理
一种方法是，采用force index强行选择一个索引。
MySQL 会根据词法解析的结果分析出可能可以使用的索引作为候选项，然后在候选列表中依次判断每个索引需要扫描多少行。如果 force index 指定的索引在候选索引列表中，就直接选择这个索引，不再评估其他索引的执行代价。
但其实使用 force index 最主要的问题还是变更的及时性。因为选错索引的情况还是比较少出现的，所以开发的时候通常不会先写上 force index。而是等到线上出现问题的时候，你才会再去修改 SQL 语句、加上 force index。但是修改之后还要测试和发布，对于生产系统来说，这个过程不够敏捷。
所以，数据库的问题最好还是在数据库内部来解决。那么，在数据库里面该怎样解决呢？
既然优化器放弃了使用某个索引，说明这个索引还不够合适，所以第二种方法就是，我们可以考虑修改语句，引导 MySQL 使用我们期望的索引。
比如，"select * from t where (a between 1 and 1000) and (b between 50000 and 100000) order by b limit 1;"
如果用索引a的话只需要扫描1000行，而用索引b要扫描50000行，那为什么优化器还是选择了索引b呢？
因为"order by b"，如果使用了索引b的话，b本身是索引，有序的，不需要再做排序，所以即使扫描行数多，也判定为代价更小。
现在 order by b,a 这种写法，要求按照 b,a 排序，就意味着使用这两个索引都需要排序。因此，扫描行数成了影响决策的主要条件，于是此时优化器选了只需要扫描 1000 行的索引 a。
第三种方法是，在有些场景下，我们可以新建一个更合适的索引，来提供给优化器做选择，或删掉误用的索引。
