MySQL| 性能分析优化
性能分析
使用EXPLAIN关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈。
表的读取顺序、哪些索引可以使用、数据读取操作的操作类型、哪些索引被实际使用、表之间的引用、每张表有多少行被物理查询（扫描）
Explain + SQL语句； 执行计划包含的信息
各个字段的名词解释：
id：select查询的序列号,包含一组数字，表示查询中执行select子句或操作表的顺序；
id相同，执行顺序由上至下；
select_type：查询的类型，主要是用于区别普通查询、联合查询、子查询等的复杂查询
- SIMPLE：简单的 select 查询,查询中不包含子查询或者UNION；
- PRIMARY：查询中若包含任何复杂的子部分，最外层查询则被标记为Primary；
- DERIVED：在FROM列表中包含的子查询被标记为DERIVED(衍生)，MySQL会递归执行这些子查询, 把结果放在临时表里。
- SUBQUERY：在SELECT或WHERE列表中包含了子查询；
- DEPENDENT SUBQUERY：在SELECT或WHERE列表中包含了子查询,子查询基于外层；
- UNCACHEABLE SUBQUREY
- UNION：若第二个SELECT出现在UNION之后，则被标记为UNION；若UNION包含在FROM子句的子查询中,外层SELECT将被标记为：DERIVED
- UNION RESULT：从UNION表获取结果的SELECT
type：
type显示的是访问类型，是较为重要的一个指标，结果值从最好到最坏依次是： system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL range:只检索给定范围的行,使用一个索引来选择行。key 列显示使用了哪个索引一般就是在你的where语句中出现了between、<、>、in等的查询
这种范围扫描索引扫描比全表扫描要好，因为它只需要开始于索引的某一点，而结束语另一点，不用扫描全部索引。
ref:非唯一性索引扫描，返回匹配某个单独值的所有行.本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而，它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体
index:出现index是sql使用了索引但是没用通过索引进行过滤，一般是使用了覆盖索引或者是利用索引进行了排序分组
system>const>eq_ref>ref>range>index>ALL 一般来说，得保证查询至少达到range级别，最好能达到ref。
key_len：表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。 key_len字段能够帮你检查是否充分的利用上了索引
如何计算 1 、先看索引上字段的类型+长度比如 int=4 ; varchar(20) =20 ; char(20) =20 2 、如果是varchar或者char这种字符串字段，视字符集要乘不同的值，比如utf-8 要乘 3,GBK要乘2， 3 、varchar这种动态字符串要加2个字节 4、 允许为空的字段要加1个字节
ref：显示索引的哪一列被使用了，如果可能的话，是一个常数（const）。哪些列或常量被用于查找索引列上的值。
Extra：
Using filesort ：说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。MySQL中无法利用索引完成的排序操作称为“文件排序”
Using where：表明使用了where过滤
最佳左前缀法则
查询优化
一、单表使用索引及常见索引失效
案例(索引失效)
①全值匹配我最爱
②最佳左前缀法则--如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。
③不在索引列上做任何操作（计算、函数、(自动or手动)类型转换），会导致索引失效而转向全表扫描
④存储引擎不能使用索引中范围条件右边的列；
⑤mysql 在使用不等于(!= 或者<>)的时候无法使用索引会导致全表扫描；
⑥is not null 也无法使用索引,但是is null是可以使用索引的；
⑦like以通配符开头('%abc...')mysql索引失效会变成全表扫描的操作；
⑧字符串不加单引号索引失效；
#批量删除某个表上的所有索引-->执行存储过程 CALL proc_drop_index("mydb","emp"); #建立3个索引 CREATE INDEX idx_age_deptId_name ON emp(age, deptId, NAME); #最佳左前缀法则 EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.age=30 AND emp.name = 'abcd' EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.deptid=1 AND emp.name = 'abcd' EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.`age` = 30 AND deptId = 4 AND emp.name = 'abcd'; #单值索引 CREATE INDEX idx_name ON emp(NAME); #索引中不能使用函数等 EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.name LIKE 'abc%' EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE LEFT(emp.name,3) = 'abc' #不能使用索引中范围条件右边的列 EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.age=30 AND emp.deptId>20 AND emp.name = 'abc' ; CREATE INDEX idx_age_name_deptid ON emp(age,NAME,deptid) #这样子建索引就都用上了; #不能使用不等于 CREATE INDEX idx_name ON emp(NAME) EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.name <> 'abc' EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.name != 'abc' #is not null 也无法使用索引,但是is null是可以使用索引的 CREATE INDEX idx_age ON emp(age); EXPLAIN SELECT * FROM emp WHERE age IS NULL EXPLAIN SELECT * FROM emp WHERE age IS NOT NULL #like以通配符开头('%abc...')mysql索引失效会变成全表扫描的操作 CREATE INDEX idx_age_name ON emp(age, NAME); EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.`age`=30 AND emp.name LIKE 'abc%' #type=range EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.`age`=30 AND emp.name LIKE '%abc%' #type=ref #字符串不加单引号索引失效 CREATE INDEX idx_name ON emp(NAME) EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.`name` = '123'; #type=ref; ref=const EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.`name` = 123;
建议：
对于单键索引，尽量选择针对当前query过滤性更好的索引；在选择组合索引的时候，当前Query中过滤性最好的字段在索引字段顺序中，位置越靠前越好。
在选择组合索引的时候，尽量选择可以能够包含当前query中的where字句中更多字段的索引；
在选择组合索引的时候，如果某个字段可能出现范围查询时，尽量把这个字段放在索引次序的最后面；
书写sql语句时，尽量避免造成索引失效的情况。
二、关联查询优化
# 下面开始explain分析 EXPLAIN SELECT * FROM book LEFT JOIN class ON class.card = book.card; #结论：type 有All # 添加索引优化 ALTER TABLE `book` ADD INDEX Y ( `card`); 换成inner join delete from class where id<5; # 第2次explain EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card; #可以看到第二行的 type 变为了 ref,rows 也变成了优化比较明显。 #这是由左连接特性决定的。LEFT JOIN 条件用于确定如何从右表搜索行,左边一定都有, #所以右边是我们的关键点,一定需要建立索引。 # 删除旧索引 + 新建 + 第3次explain DROP INDEX Y ON book; ALTER TABLE class ADD INDEX X (card); EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;
1、保证被驱动表的join字段已经被索引； 2、left join 时，选择小表作为驱动表（就是主表），大表作为被驱动表（从表）。；
3、inner join 时，mysql会自己帮你把小结果集的表选为驱动表。 4、子查询尽量不要放在被驱动表，有可能使用不到索引。
5、能够直接多表关联的尽量直接关联，不用子查询。
三、子查询优化
尽量不要使用not in 或者 not exists，用left outer join on xxx is null 替代；
##用left outer join on xxx is null 替代 EXPLAIN SELECT SQL_NO_CACHE age, COUNT(*) FROM emp e WHERE id NOT IN (SELECT ceo FROM dept d WHERE ceo IS NOT NULL) GROUP BY age HAVING COUNT(*)<10000
#加上两个索引； CREATE INDEX idx_age ON emp(age); CREATE INDEX idx_ceo ON dept(ceo); # EXPLAIN SELECT SQL_NO_CACHE age,COUNT(*) FROM emp a LEFT OUTER JOIN dept b ON a.id =b.ceo WHERE b.ceo IS NULL GROUP BY age HAVING COUNT(*)<10000
四、排序分组优化
①case
#case; 以下是否能使用到索引，能否去掉using filesort CALL proc_drop_index("mydb","emp"); CREATE INDEX idx_age_deptid_name ON emp (age,deptid,NAME) EXPLAIN SELECT SQL_NO_CACHE * FROM emp ORDER BY age,deptid; #不能使用索引,因为它没有进行过滤; EXPLAIN SELECT SQL_NO_CACHE * FROM emp ORDER BY age,deptid LIMIT 10; #可以使用索引 #无过滤 不索引（没有过滤就不会使用索引） EXPLAIN SELECT * FROM emp WHERE age=45 ORDER BY deptid; #可以去掉using filesort EXPLAIN SELECT * FROM emp WHERE age=45 ORDER BY deptid,NAME; #可以去掉using filesort EXPLAIN SELECT * FROM emp WHERE age=45 ORDER BY deptid,empno; #不能去掉using filesort EXPLAIN SELECT * FROM emp WHERE age=45 ORDER BY NAME,deptid; #不能去掉using filesort EXPLAIN SELECT * FROM emp WHERE deptid=45 ORDER BY age; #不能去掉using filesort #顺序错，必排序（与索引的顺序错了，就手动排序，不能使用上索引） EXPLAIN SELECT * FROM emp WHERE age=45 ORDER BY deptid DESC, NAME DESC ; #可以去掉using filesort; 方向都是降序 EXPLAIN SELECT * FROM emp WHERE age=45 ORDER BY deptid ASC, NAME DESC ; #不能去掉using filesort #方向反 必排序；desc与asc
②ORDER BY子句，尽量使用Index方式排序,避免使用FileSort方式排序（Extra --> Using FileSort ）
③索引的选择：执行案例前先清除emp上的索引，只留主键
#索引的选择
EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE age =30 AND empno <101000 ORDER BY NAME ;
#结论：很显然,type 是 ALL,即最坏的情况。Extra 里还出现了 Using filesort,也是最坏的情况。优化是必须的。
#开始优化：
思路： 尽量让where的过滤条件和排序使用上索引
但是一共两个字段(age,empno)上有过滤条件，一个字段(ename)有索引
1、我们建一个三个字段的组合索引可否？
CREATE INDEX idx_age_empno_name ON emp(age,empno,NAME); #只用到了age和empno索引
#我们发现using filesort 依然存在，所以name 并没有用到索引。原因是因为empno是一个范围过滤，所以索引后面的字段不会再使用索引了。
#所以我们建一个3值索引是没有意义的
DROP INDEX idx_age_empno_name ON emp
CREATE INDEX idx_age_name ON emp(age,NAME);
#也就是说empno 和name这个两个字段我只能二选其一。这样我们优化掉了 using filesort。
#但是 如果我们选择那个范围过滤，而放弃排序上的索引呢,建立
DROP INDEX idx_age_name ON emp(age, NAME);
CREATE INDEX idx_age_eno ON emp(age,empno);
#结果竟然有 filesort的 sql 运行速度，超过了已经优化掉 filesort的 sql ，而且快了好多倍。何故？
#原因是所有的排序都是在条件过滤之后才执行的，所以如果条件过滤了大部分数据的话，几百几千条数据进行排序其实并不是很消耗性能，即使索引优化了排序但实际提升性能很有限。
相对的 empno<101000 这个条件如果没有用到索引的话，要对几万条的数据进行扫描，这是非常消耗性能的，所以索引放在这个字段上性价比最高，是最优选择。
#结论:当范围条件和group by 或者 order by 的字段出现二选一时 ，优先观察条件字段的过滤数量，如果过滤的数据足够多，而需要排序的数据并不多时，优先把索引放在范围字段上。反之，亦然。
④ 如果不在索引列上，filesort有两种算法：mysql就要启动双路排序和单路排序
双路排序 MySQL 4.1之前是使用双路排序,字面意思就是两次扫描磁盘，最终得到数据， 读取行指针和orderby列，对他们进行排序，然后扫描已经排序好的列表，按照列表中的值重新从列表中读取对应的数据输出 从磁盘取排序字段，在buffer进行排序，再从磁盘取其他字段。 取一批数据，要对磁盘进行了两次扫描，众所周知，I\O是很耗时的，所以在mysql4.1之后，出现了第二种改进的算法，就是单路排序。 单路排序：从磁盘读取查询需要的所有列，按照order by列在buffer对它们进行排序，然后扫描排序后的列表进行输出，它的效率更快一些，避免了第二次读取数据。并且把随机IO变成了顺序IO,但是它会使用更多的空间， 因为它把每一行都保存在内存中了。 由于单路是后出的，总体而言好过双路，但是单路有问题： 在sort_buffer中，方法B比方法A要多占用很多空间，因为方法B是把所有字段都取出, 所以有可能取出的数据的总大小超出了sort_buffer的容量，导致每次只能取sort_buffer容量大小的数据，进行排序（创建tmp文件，多路合并），排完再取取sort_buffer容量大小，再排……从而多次I/O。 本来想省一次I/O操作，反而导致了大量的I/O操作，反而得不偿失。 优化策略： 增大sort_buffer_size参数的设置；增大max_length_for_sort_data参数的设置；减少select 后面的查询的字段。 提高Order By的速度 1. Order by时select * 是一个大忌只Query需要的字段， 这点非常重要。在这里的影响是： 1.1 当Query的字段大小总和小于max_length_for_sort_data 而且排序字段不是 TEXT|BLOB 类型时，会用改进后的算法——单路排序， 否则用老算法——多路排序。 1.2 两种算法的数据都有可能超出sort_buffer的容量，超出之后，会创建tmp文件进行合并排序，导致多次I/O，但是用单路排序算法的风险会更大一些,所以要提高sort_buffer_size。 2. 尝试提高 sort_buffer_size 不管用哪种算法，提高这个参数都会提高效率，当然，要根据系统的能力去提高，因为这个参数是针对每个进程的 1M-8M之间调整 3. 尝试提高 max_length_for_sort_data 提高这个参数， 会增加用改进算法的概率。但是如果设的太高，数据总容量超出sort_buffer_size的概率就增大，明显症状是高的磁盘I/O活动和低的处理器使用率. 1024-8192之间调整
⑤ GROUP BY关键字优化：
group by 使用索引的原则几乎跟order by一致 ，唯一区别是groupby 即使没有过滤条件用到索引，也可以直接使用索引。
五、最后使用索引的手段：覆盖索引
什么是覆盖索引？ 简单说就是，select 到 from 之间查询的列 <=使用的索引列+主键 EXPLAIN SELECT * FROM emp WHERE age <> 20; EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE NAME LIKE '%abc'; #使用覆盖索引后 EXPLAIN SELECT SQL_NO_CACHE id, age, deptId FROM emp WHERE NAME LIKE '%abc';
