在实际的生产环境中,给MySQL的字段加索引让查询的效率更高,我们往往会给MySQL的表字段加索引。MySQL具体选择哪个索引是有MySQL的优化器决定的。不知道小伙伴们有没有遇到一种情况,就是实际的查询中速度应该很快才对的,但因为MySQL选错的索引,导致查询的速度变慢了。至此,我们来看一下下面的例子。
牛刀小试
首先,我们简单创建一张表,表里面有两个字段,分别是a和b,并且我们给a和b加上索引,SQL语句执行如下:
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
接下来我们使用存储过程或者是跑代码的形式往表里插入10万条数据,此处使用存储过程,代码如下所示:
delimiter ;;
create procedure idata()
begin
declare i int;
set i=1;
while(i<=100000)do
insert into t values(i, i, i);
set i=i+1;
end while;
end;;
delimiter ;
call idata();
然后我们使用执行计划运行一条简单的SQL语句,代码如下:
explain select * from t where a between 15000 and 20000
运行之后,如下所示:
可以看到,执行这条语句的时候,MySQL使用了a上面的索引,只扫描(row)了5000条记录。想必这样的结果大家都是可以猜到的。
在这里,也许小伙伴们就会有疑问了,MySQL是怎么计算出row数的?其实,MySQL大部分时候并不能很精准的统计出这个row数,MySQL在这里主要采用的方式是抽样的方式进行计算的,即 row数 = (N个数据页不同值个数平均值) ×索引 页数。一个索引上不同的值越多,这个索引的区分度就越好。而一个索引上的不同值的个数就被称为基数。所以,row数其实严格意义上来说是不会100%精准的。
那么,我们再执行如下的SQL语句,看结果如何,代码如下:
explain select * from t where a between 5000 and 15000 and b between 10000 and 100000 order by b limit 100
其结果如下所示:
从这次的分析可以看出,MySQL最后选择了b索引,扫描了50233行数据。从这结果来看,我们不难猜出MySQL选错索引了。在MySQL中,order by 和 limit 结合使用,如果where 字段,order by字段上都有索引,那么有limit时索引会使用order by字段所在的索引,没有limit会使用where 条件的索引。造成这种原因主要是b字段上面存在索引,所以MySQL的优化器认为使用b索引可以避免排序,直接遍历然后取出相应的limit的条数就可以了,所以这里MySQL扫描的行数虽然多,但仍然被优化器认为是代价最小的。
在这里的话,由于where条件中a的范围要比b的要小,所以,这里如果使用a作为索引的话,肯定查询的速度会比b的快,所以,我们执行如下的SQL语句,进行分析下:
explain select * from t force index(a) where a between 5000 and 15000 and b between 10000 and 100000 order by b limit 100;
其结果如下图所示:
从两图可以看出,使用a索引所消耗的时间要比b索引所消耗的时间少。
优化
其实,MySQL在查询的过程中,大部分时候索引的选择都是正确的,只有偶尔会遇到以上的情况,那么,如何解决以上问题的发生呢?
1. 使用force index的形式来矫正MySQL索引的选择。不过,挺多程序员实际中并不会使用强制索引,主要是因为如果索引改了名字,这个语句也得改,显得很麻烦。而且如果以后迁移到别的数据库的话,这个语法还可能会不兼容
2. 修改MySQL语句,引导优化器去选择索引。例如在上面的例子中,可以把 order by b limit 100 改成 order by b,a limit 100,这样就意味着两个索引都要排序,优化器就会选择row行数比较少的索引。
3. 删除无效的索引,或者新建更优的索引。