慢查询日志

如何发现有问题的SQL？

使用MySql慢查日志对有效率问题的SQL进行监控

-- 查看慢查日志是否开启
show variables like 'slow_query_log';  
-- 开启慢查日志 
set global slow_query_log=on;
-- 查看日志保存位置
show variables like 'slow_query_log_file';
-- 设置日志保存位置
set global slow_query_log_file = '/home/mysql/sql_log/mysql-slow.log'; 
-- 开启索引记录
set global log_queries_not_using_indexes=on;
-- 设置时间，查询时间超过1s就记录(设置后需要重新连接数据库)
set global long_query_time=1;

日志内容分析

为了方便测试，我们可以把超时记录时间设置为0，这样就能保证有日志的记录。
当随便执行一个查询之后，打开log，观察文档最后输出

执行SQL的主机信息
# User@Host: root[root] @ localhost []  Id:    56
SQL的执行信息  执行时长，锁定时长，发送行数，扫描行数
# Query_time: 0.068822  Lock_time: 0.000372 Rows_sent: 997  Rows_examined: 24861
时间时间
SET timestamp=1528166127;
具体的语句
select * from film_list;

日志分析工具

虽然可以直接慢查询的数据都记录在了日志中，但是我们直接查看日志是不直观的，需要通过工具来快速的得到一些信息，比如：平均的查询时间，最耗时的查询语句等。
这里就介绍两款常用的日志分析工具

mysqldumpslow

mysqldumpslow是安装mysql时自带的一个工具，我们可以通过mysqldupmslow -h查看相关的帮助文档，这里我们就列举一些最常用的参数：

Usage: mysqldumpslow [ OPTS... ] [ LOGS... ]

Parse and summarize the MySQL slow query log. Options are

  -s ORDER     what to sort by (al, at, ar, c, l, r, t), 'at' is default
                al: average lock time
                ar: average rows sent
                at: average query time
                 c: count
                 l: lock time
                 r: rows sent
                 t: query time

比如我们想查询耗时最长的前十条语句，可以通过

mysqldumpslow -t 10 xxx.log

输出如下：

-- count表示该语句的执行次数
Count: 1  Time=0.07s (0s)  Lock=0.00s (0s)  Rows=997.0 (997), root[root]@localhost
  select * from film_list

pt-query-digest

pt-query-digest 安装

直接分析慢查日志

pt-query-digest xxx.log

输出的分析内容还是较多的，这里可以参考MySQL慢查询（二） - pt-query-digest详解慢查询日志

explain分析执行计划

在查找到执行较慢的SQL后，我们可以通过explain来分析sql的执行计划，比如：

explain select customer_id, first_name, last_name from customer;

结果如下：

+—-+————-+———-+——+—————+——+———+——+——+——-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+———-+——+—————+——+———+——+——+——-+
| 1 | SIMPLE | customer | ALL | NULL | NULL | NULL | NULL | 599 | NULL |
+—-+————-+———-+——+—————+——+———+——+——+——-+
1 row in set (0.00 sec)

table:：显示这一行的数据是关于哪张表的
type：显示连接使用了何种类型，从最好到最差的连接类型为const、eq_reg、ref、range、index和ALL。
- const：表明是常数查找，一般对于主键或者唯一索引，因为只有一行符合条件
- eq_reg：是一种范围查找，对于主键或者唯一索引范围里的查找
- ref：常见于联接的查询中，一个表基于某个索引的查找
- rang：基于索引的范围查找
- index：索引的扫描
- ALL：表扫描
possible_keys：显示可能应用在这张表中的索引。如果为NULL，表示没有可用的索引
key：实际使用的索引。如果为NULL，则没有使用索引
key_len：使用的索引的长度。在不损失精确性的情况下，长度越短越好。MySQL explain中key_len的计算
ref：显示索引的哪一列被使用了，如果可能的话，是一个常数
rows：MySql认为必须检查的用来返回请求数据的行数，数值越大越不好，说明没有用好索引
extra：关于mysql如何解析查询的额外信息。using temporary和using filesort是最差的情况，意思mysql根本不能使用索引，结果是检索会很慢
- Using filesort：看到这个的时候，查询就需要优化了。MySql需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行
- Using temporary：MySql需要创建一个临时表来存储结果，这通常发生在对不同的列集进行order by上，而不是group by上

Count()和Max()

首先说明一下count(*)和count(1)，它们俩在是没有什么不同的。
高性能MySQL——Count(1) OR Count(*)？
MySQL伪科学之count(1)好快

MySQL优化-基础优化