SQL优化常用方法

常见的SQL优化

sql优化三部曲

sql优化一般都是经历三个步骤:

1. 查询日志定位那条sql时间比较长,也就是查询慢
2. 通过explain等工具查询该sql的信息
3. 修改sql或者尽量让sql走索引

explain命令的结果解释

列	介绍
id	查询的序号，包含一组数字，表示查询中执行select子句或操作表的顺序 两种情况: id相同，执行顺序从上往下 id不同，id值越大，优先级越高，越先执行
select_type（重点）	查询类型，主要用于区别普通查询，联合查询，子查询等的复杂查询1、simple ——简单的select查询，查询中不包含子查询或者UNION 2、primary ——查询中若包含任何复杂的子部分，最外层查询被标记 3、subquery——在select或where列表中包含了子查询 4、derived——在from列表中包含的子查询被标记为derived（衍生），MySQL会递归执行这些子查询，把结果放到临时表中 5、union——如果第二个select出现在UNION之后，则被标记为UNION，如果union包含在from子句的子查询中，外层select被标记为derive 6、union result:UNION 的结果
table	输出的行所引用的表
type（重点）	显示联结类型，显示查询使用了何种类型，按照从最佳到最坏类型排序 1、system： 表中仅有一行（=系统表）这是const联结类型的一个特例。这是const连接类型的一种特例，表仅有一行满足条件。 2、const： 表示通过索引一次就找到，const用于比较primary key或者unique索引。因为只匹配一行数据，所以如果将主键置于where列表中，mysql能将该查询转换为一个常量,当确定最多只会有一行匹配的时候，MySQL优化器会在查询前读取它而且只读取一次，因此非常快。当主键放入where子句时，mysql把这个查询转为一个常量（高效） 3、eq_ref: 唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于唯一索引或者主键扫描,最多只返回一条符合条件的记录。使用唯一性索引或主键查找时会发生 （高效） 4、ref: 非唯一性索引扫描，返回匹配某个单独值的所有行，本质上也是一种索引访问，它返回所有匹配某个单独值的行，可能会找多个符合条件的行，属于查找和扫描的混合体,这种索引访问，它返回所有匹配某个单个值的行。此类索引访问只有当使用非唯一性索引或唯一性索引非唯一性前缀时才会发生。这个类型跟eq_ref不同的是，它用在关联操作只使用了索引的最左前缀，或者索引不是UNIQUE和PRIMARY KEY。ref可以用于使用=或<=>操作符的带索引的列。 5、range: 只检索给定范围的行，使用一个索引来选择行。key列显示使用了哪个索引，一般就是where语句中出现了between,in等范围的查询。这种范围扫描索引扫描比全表扫描要好，因为它开始于索引的某一个点，而结束另一个点，不用全表扫描,这种范围扫描key 列显示使用了哪个索引。当使用=、 <>、>、>=、<、<=、IS NULL、<=>、BETWEEN 或者 IN 操作符,用常量比较关键字列时,可以使用range. 6、index: index 与all区别为index类型只遍历索引树。通常比all快，因为索引文件比数据文件小很多,但是它和全表扫描一样。只是扫描表的时候按照索引次序进行而不是行。主要优点就是避免了排序, 但是开销仍然非常大。如在Extra列看到Using index，说明正在使用覆盖索引，只扫描索引的数据，它比按索引次序全表扫描的开销要小很多 7、all： 遍历全表以找到匹配的行 8 、null 意味说mysql能在优化阶段分解查询语句，在执行阶段甚至用不到访问表或索引（高效） 9、总结: 该列显示的是访问类型，是较为重要的一个指标，结果值从好到坏依次是：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL ，一般来说，得保证查询至少达到range级别，最好能达到ref。
possible_keys	指出MySQL能使用哪个索引在该表中找到行，但是它不一定会用，因为优化器会去评估到底用不用
key（重点）	显示MySQL实际决定使用的键(索引)。如果没有选择索引,键是NULL。查询中如果使用覆盖索引，则该索引和查询的select字段重叠。
key_len	表示索引中使用的字节数，该列计算查询中使用的索引的长度在不损失精度的情况下，长度越短越好。如果键是NULL,则长度为NULL。该字段显示为索引字段的最大可能长度，并非实际使用长度。
ref	显示索引的哪一列被使用了，如果有可能是一个常数，哪些列或常量被用于查询索引列上的值
rows	根据表统计信息以及索引选用情况，大致估算出找到所需的记录所需要读取的行数
filtered	显示了通过条件过滤出的行数的百分比估计值
Extra（每个版本都可能不一样，这个也只是参考项）	包含不适合在其他列中显示，但是十分重要的额外信息 1、Using filesort：说明mysql会对数据适用一个外部的索引排序。而不是按照表内的索引顺序进行读取。MySQL中无法利用索引完成排序操作称为“文件排序” 2、Using temporary:使用了临时表保存中间结果 (但是并不知道是磁盘临时表还是内存临时表) ，mysql在查询结果排序时使用临时表。常见于排序order by和分组查询group by。建议放到程序处理 3、Using index:表示相应的select操作用使用覆盖索引，避免访问了表的数据行。如果同时出现using where，表名索引被用来执行索引键值的查找；如果没有同时出现using where，表名索引用来读取数据而非执行查询动作。 4、Using where :表明使用where过滤 5、using join buffer:使用了连接缓存,常见于left join,right join 尽量避免用左右关联,最多2表join 6、impossible where:where子句的值总是false，不能用来获取任何元组 7、select tables optimized away：在没有group by子句的情况下，基于索引优化Min、max操作或者对于MyISAM存储引擎优化count（*），不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。 8、distinct：优化distinct操作，在找到第一匹配的元组后即停止找同样值的动作。 9、Using sort_union(…), Using union(…), Using intersect(…):这些函数说明如何为index_merge联接类型合并索引扫描。 10、Using index for group-by:类似于访问表的Using index方式,Using index for group-by表示MySQL发现了一个索引,可以用来查 询GROUP BY或DISTINCT查询的所有列,而不要额外搜索硬盘访问实际的表。

SQL优化主要是查询部分,个人理解就是尽量走索引,主要优化的也只有两部分,那就是插入和查询
先查看自己mysql的配置
show variables like ‘%quer%’;

参数	含义
slow_query_log	慢查询是否开启,on开始,off关闭
long_query_time	sql执行时间超过多少秒会被记录到慢查询日志中
slow_query_log_file	慢查询sql存储位置

查询操作期间有多少次慢sql被记录了;
show status like ‘%slow_queries%’;
执行后的value就是慢sql条数.

sql后加force index可强制该条sql使用哪个索引

通过上边的两个sql就可以定位慢sql,然后对慢sql进行分析

插入

情况	解决方式
一般批量插入时	inset into 表名 values(列名1,列明2…),(…),(…),如果是mysql,设置mysql的max_allowed_packet参数大一点,MyISAM需要注意bulk_insert_buffer_size缓存大小
大数据量插入时	1. 采用load sql文件的方式      1.1 load数据文件的时候如果是MyISAM可以再导入时通过ALTER TABLE tablename DISABLE KEYS；关闭表非唯一索引的更新,导入后再通过ALTER TABLE tablename ENABLE KEYS；打开,       1.2 对于InnoDB则在导入数据前执行 SET UNIQUE_CHECKS=0，关闭唯一性效验，在导入数据结束以后执行SET UNIQUE_CHECKS=1，恢复唯一性效验，可以提高导入效率。如果使用自动提交的方式，建议在导入前执行SET AUTOCOMMIT=0，关闭自动提交，导入结束后再执行SET AUTOCOMMIT=1，打开自动提交，也可以提高导入的效率      1.3 尽量让插入的数据保持有序性,这样简历索引的时候也快一点. 2. 批量使用inset into 表名 values(列名1,列明2…),(…),(…)来减少数据库连接,但是有出错风险,数据要求不高可采用.例如: inset into 表名 values(列名1,列明2…),(…),(…); inset into 表名 values(列名1,列明2…),(…),(…); inset into 表名 values(列名1,列明2…),(…),(…);

查询

sql	优化
*	不要用*,不要用*,不要用*重要的事情说三遍
函数运算	查询条件尽量不要用函数运算,查询内容也尽量少用
order by	默认是不走索引的,如果有索引,order by后的字段尽量用索引或主键,并且order by 的顺序和索引顺序（如果复合索引,最左匹配原则）相同,order by 字段都是同为升序或者降序,如果还是不行,尽量放到代码处理,不要做无谓的排序，尽可能在索引中完成排序，不需要排序的可以写成 order by null,如果碰到group by的同时又要order by的,建议建立联合索引去解决,如果遇到creating sort index耗时问题也可以考虑用SQL_BIG_RESULT或增大点临时表空间尝试一下
group by	group by分组的时候一般都会先进行排序,如果不要求排序可以用group by null去除排序只分组,如果碰到千万或者亿级数据,可以考虑采用分批次查询来优化分组的sql操作,放到代码去处理分组.
join	尽量用join来代替子查询或嵌套查询,因为join不会创建临时表,不要使用left join和right join,因为有很多坑,比如说left join会因为前边的驱动表造成后边的表没数据填充NULL的情况,null值会造成索引失效问题,尽量保持最多2表join,关联字段也尽量用索引字段,使用 join 时应该小结果集驱动大结果集，同时把复杂的 join 查询拆分成多个 query， 不然 join 越多表，会导致越多的锁定和堵塞
or	如果or的两侧都用到了唯一索引可使用,如果两侧组成复合索引用union或union all代替or来合并结果,不然效率低的程度可能超过全表扫描
like	like的%用后不用前,前边加%会造成不走索引的情况,如果必须全模糊可以考虑用反转或搜索引擎解决
not in	使用not exist来代替not in
in和exist	1.外表量比里表数据量小用exists； 2.外表量比里表数据量大用in;3.不管那个大哪个小,not都用not exists;
索引字段	避免在索引字段上使用<>，!=,避免在索引列上使用IS NULL和IS NOT NULL, 避免在索引列上出现数据类型转换（比如某字段是String类型，参数传入时是int类型）这些都会造成不走索引
limit分页	limit x,y的意思是扫描x+y行,丢弃x行返回y行,如果x不做处理,会造成全表扫描,如果用数据库自增id的情况下,可以采用(page-1)*pagesize+1去过滤id值，加where id>公式 limit pageSize,排序的字段最好有索引,或者是用回表的方式先定位数据id再limit,也可以用between and来代替
1=1问题	1=1会影响索引的效果,没索引的表可以考虑,有索引的尽量别用,如果用的是mybatis框架,可以用< where> 标签加< if>做处理,where标签会自动处理第一个多出and的条件
null	表字段如果会用到索引必须设置为not null,不然会造成索引失效问题,并且null实际占4个字节,表字段能不设置null尽量不设置,可以加默认值，而且null在索引中是被单独处理放到一起的，可能都在同一个数据页等等
字符集	所有的表字段全部采用同一种字符集,尽量避免不同字符集的情况,字段字符集不同在做关联时,会造成索引失效问题.
time问题	表字段一般采用datetime做时间类型,但是sql中查询,‘2019-01-01 12:12:12’ >= xxx字段要比时间戳的方式快,如果字段类型改为long类型,用时间戳的方式比字符串时间的方式还要快.
改表字段类型或默认值	alter table 表 alter column 字段 set default 值
count()	count(字段/1)会抛弃null的行,count(*)比较靠谱
索引失效	查询的行数占总数据量的比例过多时,貌似是50%,mysql的优化器会转化成全表查询
rand函数	不要使用 rand 函数随机获取记录
函数运算	避免在列上做运算，可能会导致索引失败
where	尽可能在where中多加条件用来缩小数据范围
from	From 语句中尽量不要使用子查询
查询表总条数	查询表总条数，在数据量大的时候尽量用 show table status like ‘表名’；语句来查，结果的rows列就是行数
持续更新	有时间继续写

其他知识点

1. 如何优雅的删除线上较大的慢查询日志文件?

	可以先将慢查询日志文件修改名称充当备份,当你修改名称之后因为句柄未发生改变,所以慢查询一样会纪录
	到你修改过名字的文件里,此时,在mysql的客户端执行 flush slow logs;命令,就可以刷新句柄完成慢日
	志文件的重置,然后你就可以随意处理之前的大文件日志了.