很高兴！终于踩到了慢查询的坑

以前看了饿了么团队写的一篇博客：等等！这两个 Spring-RabbitMQ 的坑咱们已经替你踩了。深受启发，必定要取个能吸引读者眼球的标题，固然除了响当当的标题之外，内容也要是干货。为何会想取这样一个标题，由于看了理论上的慢查询优化，今天！！！终于在生产上实战了

(一)慢sql一

问题发现

将应用发布到生产环境后，前端页面请求后台API返回数据，发现至少须要6s。查看到慢sql：

复现慢sql

执行sql：

select count(*) from sync_block_data
where unix_timestamp(sync_dt) >= 1539101010
AND unix_timestamp(sync_dt) <= 1539705810
复制代码

查看耗时：

一共耗时为2658ms 查看执行计划：

explain select count(*) from sync_block_data
where unix_timestamp(sync_dt) >= 1539101010
AND unix_timestamp(sync_dt) <= 1539705810
复制代码

执行计划结果：

优化慢sql一

sync_dt的类型为datetime类型。换另一种sql写法，直接经过比较日期而不是经过时间戳进行比较。将sql中的时间戳转化为日期，分别为2018-10-10 00:03:30和2018-10-17 00:03:30 执行sql：

select count(*) from sync_block_data
where sync_dt >= "2018-10-10 00:03:30"
AND sync_dt <= "2018-10-17 00:03:30"
复制代码

查看耗时：

一共耗时419毫秒，和慢查询相比速度提高六倍多 查看执行计划：

explain select count(*) from sync_block_data
where sync_dt >= "2018-10-10 00:03:30"
AND sync_dt <= "2018-10-17 00:03:30"
复制代码

执行计划结果：

访问页面，优化完成后请求时间平均为900毫秒

执行计划中慢查询和快查询惟一的区别就是type不同：慢查询中type为index，快查询中type为range。

优化慢查询二

这条sql的业务逻辑为统计出最近七天该表的数据量，能够去掉右边的小于等于 执行sql：

select count(*) from sync_block_data
where sync_dt >= "2018-10-10 00:03:30"
复制代码

查看耗时：

一共耗时275毫秒，又将查询时间减小了一半 查看执行计划：

explain select count(*) from sync_block_data
where sync_dt >= "2018-10-10 00:03:30"
复制代码

执行计划结果：

type还是range。可是经过少比较一次将查询速度提升一倍

优化慢查询三

新建一个bigint类型字段sync_dt_long存储sync_dt的毫秒值，并在sync_dt_long字段上创建索引 测试环境下： 优化慢查询二sql

select count(*) from copy_sync_block_data
where sync_dt >="2018-10-10 13:15:02"
复制代码

耗时为34毫秒 优化慢查询三sql

select count(*) from copy_sync_block_data
where sync_dt_long >= 1539148502916
复制代码

耗时为22毫秒 测试环境中速度提高10毫秒左右

优化慢查询三sql测试小结：在InnoDB存储引擎下，比较bigint的效率高于datetime 完成三步优化之后生产环境中请求耗时：

速度又快了200毫秒左右。经过给查询的数据加10s缓存，响应速度最快平均为20ms

explain使用介绍

经过explain，能够查看sql语句的执行状况（好比查询的表，使用的索引以及mysql在表中找到所需行的方式等） 用explain查询mysql查询计划的输出参数有:

列名	说明
id	执行编号，标识select所属的行。若是在语句中没子查询或关联查询，只有惟一的select，每行都将显示1。不然，内层的select语句通常会顺序编号，对应于其在原始语句中的位置
select_type	显示本行是简单或复杂select。若是查询有任何复杂的子查询，则最外层标记为PRIMARY（DERIVED、UNION、UNION RESUlT）
table	访问引用哪一个表（引用某个查询，如“derived3”）
type	数据访问/读取操做类型（ALL、index、range、ref、eq_ref、const/system、NULL）
possible_keys	揭示哪一些索引可能有利于高效的查找
key	显示mysql决定采用哪一个索引来优化查询
key_len	显示mysql在索引里使用的字节数
ref	显示了以前的表在key列记录的索引中查找值所用的列或常量
rows	为了找到所需的行而须要读取的行数，估算值，不精确。经过把全部rows列值相乘，可粗略估算整个查询会检查的行数
Extra	额外信息，如using index、filesort等

重点关注type，type类型的不一样居然致使性能差六倍！！！

type显示的是访问类型，是较为重要的一个指标，结果值从好到坏依次是： system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL ，通常来讲，得保证查询至少达到range级别，最好能达到ref。

类型	说明
All	最坏的状况,全表扫描
index	和全表扫描同样。只是扫描表的时候按照索引次序进行而不是行。主要优势就是避免了排序, 可是开销仍然很是大。如在Extra列看到Using index，说明正在使用覆盖索引，只扫描索引的数据，它比按索引次序全表扫描的开销要小不少
range	范围扫描，一个有限制的索引扫描。key 列显示使用了哪一个索引。当使用=、 <>、>、>=、<、<=、IS NULL、<=>、BETWEEN 或者 IN 操做符,用常量比较关键字列时,可使用 range
ref	一种索引访问，它返回全部匹配某个单个值的行。此类索引访问只有当使用非惟一性索引或惟一性索引非惟一性前缀时才会发生。这个类型跟eq_ref不一样的是，它用在关联操做只使用了索引的最左前缀，或者索引不是UNIQUE和PRIMARY KEY。ref能够用于使用=或<=>操做符的带索引的列。
eq_ref	最多只返回一条符合条件的记录。使用惟一性索引或主键查找时会发生 （高效）
const	当肯定最多只会有一行匹配的时候，MySQL优化器会在查询前读取它并且只读取一次，所以很是快。当主键放入where子句时，mysql把这个查询转为一个常量（高效）
system	这是const链接类型的一种特例，表仅有一行知足条件。
Null	意味说mysql能在优化阶段分解查询语句，在执行阶段甚至用不到访问表或索引（高效）

出现慢查询的缘由

在where子句中使用了函数操做 出现慢查询的sql语句中使用了unix_timestamp函数统计出自'1970-01-01 00:00:00'的到当前时间的秒数差。致使索引全扫描统计出近七天的数据量的

解决方案

尽可能避免在where子句中对字段进行函数操做，这将致使存储引擎放弃使用索引而进行全表扫描。对于须要计算的值最好经过程序计算好传入而不是在sql语句中作计算，好比这个sql中咱们将当前的日期和七天前的日期计算好传入

后记

这个问题当时在测试环境没有发现，测试环境的请求速度仍是能够的。没有被发现能够归结为数据量。生产数据量为百万级别，测试环境数据量为万级，数据量差50倍，数据量的增大把慢查询的问题也放大了。

(二)慢sql二

由于线上出现了很明显的请求响应慢的问题，又去看了项目中的其余sql，发现还有sql执行的效率比较低

复现慢sql

执行sql

select FROM_UNIXTIME(copyright_apply_time/1000,'%Y-%m-%d') point,count(1) nums
from resource_info where copyright_apply_time >= 1539336488355 and copyright_apply_time <= 1539941288355 group by point
复制代码

查看耗时：

耗时为1123毫秒 查看执行计划：

explain select FROM_UNIXTIME(copyright_apply_time/1000,'%Y-%m-%d') point,count(1) nums
from resource_info where copyright_apply_time >= 1539336488355 and copyright_apply_time <= 1539941288355 group by point
复制代码

执行计划结果：

索引是命中了，可是extra字段中出现了Using temporary和Using filesort

优化慢sql一

group by实质是先排序后分组，也就是分组以前必排序。经过分组的时候禁止排序优化sql 执行sql：

select FROM_UNIXTIME(copyright_apply_time/1000,'%Y-%m-%d') point,count(1) nums
from resource_info where copyright_apply_time >= 1539336488355 and copyright_apply_time <= 1539941288355 group by point order by null
复制代码

查看耗时：

一共耗时1068毫秒，提升100毫秒左右，效果并非特别明显 查看执行计划：

extra字段已经没有Using filesort了，filesort表示经过对返回数据进行排序。全部不是经过索引直接返回排序结果的排序都是FileSort排序，说明优化后经过索引直接返回排序结果 Using temporary依然存在，出现Using temporary表示查询有使用临时表, 通常出现于排序, 分组和多表join的状况, 查询效率不高, 仍须要进行优化，这里出现临时表的缘由是数据量过大使用了临时表进行分组运算

优化慢sql二

慢查询的sql业务逻辑为根据时间段分类统计出条件范围内各个时间段的数量 好比给定的条件范围为2018-10-20~2018-10-27的时间戳，这条sql就会统计出2018-10-20～2018-10-27天天的数据增量。如今优化成一天一天查，分别查七次数据，去掉分组操做

select FROM_UNIXTIME(copyright_apply_time/1000,'%Y-%m-%d') point,count(1) nums
from resource_info where copyright_apply_time >= 1539855067355 and copyright_apply_time <= 1539941467355 
复制代码

查看耗时：

耗时为38毫秒，即便查7次所用时间也比1123毫秒少 查看执行计划：

extra字段中和慢查询的extra相比少了Using temporary和Using filesort。完美

就这样第一次经历了真正的慢查询以及慢查询优化，终于理论和实践相结合了