广告============================================广告(可略过广告部分)
花了一周时间摸了一下MySql的优化,也花了时间做了一张思维导图,如果有需要的同学可以在下面留个言,留个邮箱,在下免费发送给你。因为想要骗个赞和访问量什么的~
正文==============================================正文
SQL性能问题
1.分析sql 的执行计划
分析:模拟SQL优化器执行SQL语句的执行顺序
2.sql优化器的干扰sql语句优化
连表查询-数据量小的表先查询,数据量大的表后查询
ID相同,从上往下依次执行
连表查询或者子查询,Id有相同的,有不同的,Id值越大越优先查询
分析explain SQL执行计划与Type级别详解
system>const>eq_ref>ref>range>index>ALL
越往左边,性能越高,比如system就比ALL类型性能要高出许多,其中system、const只是理想类型,基本达不到;
实际能优化到ref>range这两个类型,就是你自己写SQL,如果你没优化基本上就是ALL,如果你优化了,那就尽量达到ref>range这两个级别;
Type级别详解
system级别
1.只有一条数据的系统表
2.或衍生表只能有一条数据的主查询
const级别
1.仅仅能查出一条的SQL语句并且用于Primary key 或 unique索引;
eq_ref级别
唯一性索引:对于每个索引键的查询,返回匹配唯一行数据(有且只有1个,不能多,不能0);
ref级别
非唯一性索引:对于每个索引键的查询,返回匹配的所有行(可以是0,或多个)
range级别
检索指定范围的行,查找一个范围内的数据,where后面是一个范围查询 (between,in,> < >=);
in有时候会失效,导致变成扫描全表->all级别
index级别
查询全部索引中的数据
只查询全部索引
ALL级别
查的这一列不是索引,就会导致全表扫描,所以要避免全表扫描;
分析explain SQL执行计划与Extra
Using filesort
主要出现在 order by 排序、复合索引跨列;
order by 排序出现解决方案:根据什么查询,就根据什么排序
where name1=?,就order by name1
复合索引跨列
在复合索引下,必须要从左一次向右走,不得从中间往后,也不能跨列,否则就会出现Usein filesort;
避免策略:where 和 order by 按照复合索引的顺序使用,不要跨列或无序使用
Useing temporary
主要出现在:group by分组中
同样也是性能损耗较大,用到了临时表,如果在执行的时候出现了Useing temporary,它就不单单的在查你条件中的表,而又多出来了一张表,多了这张表,你的性能就必然损耗了;
避免Useing temporary策略:查询那些列,就根据那些列进行分组 group by;
Using index
表明这条sql性能提升
不读取源文件,只从索引文件中获取数据(不需要回表查询)
只要使用到的列全部都在索引中,就是索引覆盖 using index;
Using where
需要回表查
数据既在原表中,也在索引中,这个时候就不得不导致需要回表查
查询a,b两个属性,where a=? a是索引列,b不是,所以就需要回表查询
截图部分(屏幕小截不完):