1. 关联查询优化
1.1 建表语句
CREATE TABLE IF NOT EXISTS `class` (
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`card` INT(10) UNSIGNED NOT NULL,
PRIMARY KEY (`id`)
);
CREATE TABLE IF NOT EXISTS `book` (
`bookid` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`card` INT(10) UNSIGNED NOT NULL,
PRIMARY KEY (`bookid`)
);
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
1.2 案例SQL
# 下面开始explain分析
EXPLAIN SELECT SQL_NO_CACHE * FROM class LEFT JOIN book ON class.card = book.card;
可以看到连接查询中,两个表都是全表扫描,一个表扫描20行,总共就是400行。
添加索引优化:
ALTER TABLE `book` ADD INDEX Y (`card`);
EXPLAIN SELECT SQL_NO_CACHE * FROM class LEFT JOIN book ON class.card = book.card;
可以看到第二个表已经不是全表扫描了,用到了索引。
把第二个表的card字段也建立索引:
ALTER TABLE `class` ADD INDEX Y (`card`);
EXPLAIN SELECT SQL_NO_CACHE * FROM class LEFT JOIN book ON class.card = book.card;
虽然第一个表用到了索引,但是还是全表扫描。因为这是覆盖索引。
两个表关联查询,第一个表叫驱动表,第二个表叫被驱动表,驱动表避免不了全表扫描,应该给被驱动表关联字段建索引。
在内连接中,由mysql自己选择驱动表和被驱动表。左连接和右连接是由用户自己选择驱动表和被驱动表的。
1.3 建议
- 保证被驱动表的join字段已经被索引
- left join 时,选择小表作为驱动表,大表作为被驱动表。
- inner join 时,mysql会自己帮你把小结果集的表选为驱动表。
- 子查询尽量不要放在被驱动表,有可能使用不到索引。
- 能够直接多表关联的尽量直接关联,不用子查询。
2. 子查询优化
找出不是掌门人的人
# 方式一 使用not in
select * from t_emp e where e.id not in (select d.ceo from t_dept d where d.ceo is not null);
# 方式二:优化
select * from t_emp e left join t_dept d on e.id = d.ceo where d.id is null;
方式一使用了子查询,而且使用了is not null,而方式二没有用子查询,没有用到is not null,可以用到索引,使用了关联查询,这个就是优化了子查询。
总结:尽量不要使用not in 或者 not exists。用left outer join on 或者 is null 替代。
3. 排序分组优化
3.1 案例
不加索引时:
explain select SQL_NO_CACHE * from emp order by age,deptid;
使用了Using filesort,没有索引,会全表扫描,效果差。
create index idx_age_deptid_name on emp (age,deptid,name)
建立索引后还是Using filesort。
但是下面的sql,没有使用到Using filesort,没有全表扫描
explain select SQL_NO_CACHE * from emp order by age,deptid limit 10;
总结:order by想用到索引,必须使用过滤条件。
create index idx_age_deptid_name on emp (age,deptid,name)
explain select * from emp where age=45 order by deptid;
可以看到,用上了索引。
create index idx_age_deptid_name on emp (age,deptid,name)
explain select * from emp where age=45 order by deptid,name;
也用上了索引。
create index idx_age_deptid_name on emp (age,deptid,name)
explain select * from emp where age=45 order by deptid,empno;
同样用到了索引。
explain select * from emp where age=45 order by name,deptid;
order by后面没用上索引,where用上了索引。
explain select * from emp where deptid=45 order by age;
where后面和order by后面都没用到索引。
总结:order by后面用到的索引顺序错误,就会使用到Using filesort。
create index idx_age_deptid_name on emp (age,deptid,name)
explain select * from emp where age=45 order by deptid desc, name desc ;
使用到了索引。
explain select * from emp where age=45 order by deptid asc, name desc ;
没用到索引。
总结:排序的方向相反,排序用不到索引。
ORDER BY子句,尽量使用Index方式排序,避免使用FileSort方式排序
3.2 索引选择
#查询 年龄为30岁的,且员工编号小于101000的用户,按用户名称排序
EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE age =30 AND empno < 101000 ORDER BY name;
结论:很显然,type 是 ALL,即最坏的情况。Extra 里还出现了 Using filesort,也是最坏的情况。优化是必须的。
开始优化:思路:尽量让where的过滤条件和排序使用上索引
CREATE INDEX idx_age_empno_name ON emp(age,empno,NAME);
我们发现using filesort 依然存在,所以name 并没有用到索引。
因为empno是一个范围过滤,所以索引后面的字段不会再使用索引了。所以我们建一个3值索引是没有意义的 。
那么我们先删掉这个索引,建立一个2值索引的。
CREATE INDEX idx_age_name ON emp(age,NAME);
这样我们优化掉了 using filesort。
当两个索引都存在时,mysql会选择最优的那个:
当范围条件和group by 或者 order by 的字段出现二选一时 ,优先观察条件字段的过滤数量,如果过滤的数据足够多,而需要排序的数据并不多时,优先把索引放在范围字段上。反之,亦然。
3.3 filesort两种算法
order by如果不在索引列上,filesort有两种算法:mysql就要启动双路排序和单路排序
例子:
select * from user where name = "张三" order by age
双路排序:MySQL 4.1之前是使用双路排序,字面意思就是两次扫描磁盘,最终得到数据,读取行指针和orderby列,对他们进行排序,然后扫描已经排序好的列表,按照列表中的值重新从列表中读取对应的数据输出。从磁盘取排序字段,在buffer进行排序,再从磁盘取其他字段。
取一批数据,要对磁盘进行了两次扫描,众所周知,I\O是很耗时的,所以在mysql4.1之后,出现了第二种改进的算法,就是单路排序。
以上面的例子:
①从索引 name 找到第一个满足 name = ‘张三’ 的主键id
②根据主键 id 取出整行,把排序字段 age 和主键 id 这两个字段放到 sort buffer(排序缓存) 中
③从索引 name 取下一个满足 name = ‘张三’ 记录的主键 id
④重复 3、4 直到不满足 name = ‘张三’
⑤对 sort_buffer 中的字段 age 和主键 id 按照字段 age进行排序
⑥遍历排序好的 id 和字段 age ,按照 id 的值回到原表中取出 所有字段的值返回给客户端
单路排序:从磁盘读取查询需要的所有列,按照order by列在buffer对它们进行排序,然后扫描排序后的列表进行输出,它的效率更快一些,避免了第二次读取数据。并且把随机IO变成了顺序IO,但是它会使用更多的空间,因为它把每一行都保存在内存中了。
以上面的例子:
①从索引 name 找到第一个满足 name = ‘张三’ 的主键id
②根据主键 id 取出整行,取出所有字段的值,存入 sort_buffer(排序缓存)中
③从索引name找到下一个满足 name = ‘张三’ 条件的主键 id
④重复步骤 2、3 直到不满足 name = ‘张三
⑤返回结果给客户端
总结:至于mysql优化器使用双路排序还是单路排序是有自己的算法判断的,如果查询的列字段大于max_length_for_sort_data变量,则会使用双路排序,反之则会使用单路排序,单路排序速度是更快的,不过比较占据内存,如果在内存空间允许的情况下想要使用单路排序的话,可以增加max_length_for_sort_data变量的大小,max_length_for_sort_data变量默认为1024字节。
优化策略:
①增大sort_buffer_size参数的设置
②增大max_length_for_sort_data参数的设置
③减少select 后面的查询的字段。
why?
提高Order By的速度
- Order by时select * 是一个大忌,只Query需要的字段, 这点非常重要。在这里的影响是:
1.1 当Query的字段大小总和小于max_length_for_sort_data 而且排序字段不是 TEXT|BLOB 类型时,会用改进后的算法——单路排序, 否则用老算法——多路排序。
1.2 两种算法的数据都有可能超出sort_buffer的容量,超出之后,会创建tmp文件进行合并排序,导致多次I/O,但是用单路排序算法的风险会更大一些,所以要提高sort_buffer_size。 - 尝试提高 sort_buffer_size
不管用哪种算法,提高这个参数都会提高效率,当然,要根据系统的能力去提高,因为这个参数是针对每个进程的 1M-8M之间调整 - 尝试提高 max_length_for_sort_data
提高这个参数, 会增加用改进算法的概率。但是如果设的太高,数据总容量超出sort_buffer_size的概率就增大,明显症状是高的磁盘I/O活动和低的处理器使用率. 1024-8192之间调整
3.4 GROUP BY关键字优化
group by 使用索引的原则几乎跟order by一致 ,唯一区别是groupby 即使没有过滤条件用到索引,也可以直接使用索引。
3.5 最后使用索引的手段:覆盖索引
什么是覆盖索引?
简单说就是,select 到 from 之间查询的列
explain select * from emp where name like ‘%abc’;
使用覆盖索引后