一个SQL语句使用了索引,为什么还是会进入到慢查询之中呢?
案例浅析
创建一张表,一个主键,一个普通索引
CREATE TABLE `T`(
`id` int(11) NOT NULL,
`a` int(11) DEFAUT NULL,
PRIMARY KEY(`id`),
KEY `a`(`a`)
) ENGINE=InnoDB;
该表有三个字段,其中用id是主键索引,a是普通索引。首先SQL判断一个语句是不是慢查询语句,用的是语句的执行时间。
语句执行过程中有没有用到表的索引,可以通过explain一个语句的输出结果来看KEY的值不是NULL。
我们看下 explain select * from t;的KEY结果是NULL
我们看下explain select * from t where id=2;的KEY结果是PRIMARY,就是我们常说的使用了主键索引
我们看下explain select a from t;的KEY结果是a,表示使用了a这个索引。
虽然后两个查询的KEY都不是NULL,但是最后一个实际上扫描了整个索引树a。
假设这个表的数据量有100万行,第二个的语句还是可以执行很快,但是第三个就肯定很慢了。如果是更极端的情况,比如,这个数据库上CPU压力非常的高,那么可能第2个语句的执行时间也会超过long_query_time,会进入到慢查询日志里面。
所以我们可以得出一个结论:是否使用索引和是否进入慢查询之间并没有必然的联系。使用索引只是表示了一个SQL语句的执行过程,而是否进入到慢查询是由它的执行时间决定的,而这个执行时间,可能会受各种外部因素的影响。换句话来说,使用了索引你的语句可能依然会很慢。
我们都知道,InnoDB是索引组织表,所有的数据都是存储在索引树上面的。比如上面的表t,这个表包含了两个索引,一个主键索引和一个普通索引。在InnoDB里,数据是放在主键索引里的。如图所示:
可以看到数据都放在主键索引上,如果从逻辑上说,所有的InnoDB表上的查询,都至少用了一个索引,所以现在我问你一个问题,如果你执行select from t where id>0,你觉得这个语句有用上索引吗?
我们看上面这个语句的explain的输出结果显示的是PRIMARY。其实从数据上你是知道的,这个语句一定是做了全面扫描。但是优化器认为,这个语句的执行过程中,需要根据主键索引,定位到第1个满足ID>0的值,也算用到了索引。
你现在知道了,使用索引的语句也有可能是慢查询,我们的查询优化的过程,往往就是减少扫描行数的过程。
添加索引:
1. 添加PRIMARY KEY(主键索引):ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` )
2. 添加UNIQUE(唯一索引) :ALTER TABLE `table_name` ADD UNIQUE ( `column` )
3. 添加INDEX(普通索引) :ALTER TABLE `table_name` ADD INDEX index_name ( `column` )
4. 添加多列索引 :ALTER TABLE `table_name` ADD INDEX index_name ( `column1`, `column2`, `column3` )
记录下来,还需深入理解应用。