选错索引的原因
选择索引是优化器的工作。而优化器选择索引的目的，是找到一个最优的执行方案，并用最小的代价去执行语句。在数据库里面，扫描行数是影响执行代价的因素之一。扫描的行数越少，意味着访问磁盘数据的次数越少，消耗的 CPU 资源越少。
当然，扫描行数并不是唯一的判断标准，优化器还会结合是否使用临时表、是否排序，是否需要回表查询等因素进行综合判断。
新建一张表
CREATE TABLE `t` (
`id` int(11) NOT NULL,
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `a` (`a`),
KEY `b` (`b`)
) ENGINE=InnoDB；然后，我们往表 t 中插入 10 万行记录，取值按整数递增，即：(1,1,1)，(2,2,2)，(3,3,3) 直到 (100000,100000,100000)。执行如下语句：
看一个例子：
mysql> select * from t where (a between 1 and 1000) and (b between 50000 and 100000) order by b limit 1;从条件上看，这个查询没有符合条件的记录，因此会返回空集合。如果你来选择索引，会选择哪一个呢？
如果使用索引 a 进行查询，那么就是扫描索引 a 的前 1000 个值，然后取到对应的 id，再到主键索引上去查出每一行，然后根据字段 b 来过滤。显然这样需要扫描 1000 行。
如果使用索引 b 进行查询，那么就是扫描索引 b 的最后 50001 个值，与上面的执行过程相同，也是需要回到主键索引上取值再判断，所以需要扫描 50001 行。所以你一定会想，如果使用索引 a 的话，执行速度明显会快很多。那么，下面我们就来看看到底是不是这么一回事儿。
通过explain命令查看语句执行情况
使用 explain 命令查看语句执行情况
key的这一列，表示的是优化器选择的索引列。可以看到，返回结果中 key 字段显示，这次优化器选择了索引 b，而 rows 字段显示需要扫描的行数是 50198。
这里优化器选择使用索引 b，是因为它认为使用索引 b 可以避免排序(b 本身是索引，已经是有序的了，如果选择索引 b 的话，不需要再做排序，只需要遍历)，所以即使扫描行数多，也判定为代价更小。
解决方法
对于由于索引统计信息不准确导致的问题，通过analyze table tableName命令，可以重新统计索引信息，这个可以解决大部分情况的问题。使用之后再次使用explain命令查看。
而对于其他优化器误判的情况，可以在应用端用 force index 来强行指定索引，也可以通过修改语句来引导优化器，还可以通过增加或者删除索引来绕过这个问题。
set long_query_time=0;
select * from t where a between 10000 and 20000;
//强行是下面的语句走a这个索引。
select * from t force index(a) where a between 10000 and 20000;
