## 1、数据准备
**演示数据库**
使用MySQL提供的sakila数据库，可以通过以下URL获取这个演示数据库
[https://dev.mysql.com/doc/index-other.html](https://dev.mysql.com/doc/index-other.html)
sakila数据库的表结构信息可以通过以下网站查看
[https://dev.mysql.com/doc/sakila/en/sakila-installation.html](https://dev.mysql.com/doc/sakila/en/sakila-installation.html)
数据库基于MySQL5.5 版本
why？不同MySQL版本的优化器有一定的差别。
## 2、查询mysql的操作信息
```
show status -- 显示全部mysql操作信息
show status like "com_insert%"; -- 获得mysql的插入次数;
show status like "com_delete%"; -- 获得mysql的删除次数;
show status like "com_select%"; -- 获得mysql的查询次数;
show status like "uptime"; -- 获得mysql服务器运行时间
show status like 'connections'; -- 获得mysql连接次数
```
show [session|global] status like .... 如果你不写 [session|global] 默认是session 会话，只取出当前窗口的执行，如果你想看所有(从mysql 启动到现在，则应该 global)
>通过查询mysql的读写比例,可以做相应的配置优化;
## 3、慢查询运行状态
当Mysql性能下降时，通过开启慢查询来获得哪条SQL语句造成的响应过慢，进行分析处理。**当然开启慢查询会带来CPU损耗与日志记录的IO开销，所以我们要间断性的打开慢查询日志来查看Mysql运行状态。**
慢查询能记录下所有执行超过long_query_time时间的SQL语句, 用于找到执行慢的SQL, 方便我们对这些SQL进行优化.
```
show variables like "%slow%";-- 是否开启慢查询;
show status like "%slow%"; -- 查询慢查询SQL状况;
show variables like "long_query_time"; -- 慢查询时间
```
## 4、慢查询开启设置
```
mysql> show variables like 'long_query_time'; -- 默认情况下，mysql认为10秒才是一个慢查询
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
mysql> set long_query_time=1; -- 修改慢查询时间,只能当前会话有效;(通常为100ms或者0.01m)
mysql> set global slow_query_log='ON';-- 启用慢查询 ,加上global，不然会报错的;
set global slow_query_log_file=/'home/mysql/sql_log/mysql-slow.log' //记录日志的log文件
set global log_queries_not_using_indexes=on;（开启 记录没有使用索引查询语句）
```
也可以在配置文件中更改
修改mysql配置文件my.ini[windows]/my.cnf[Linux]加入,**注意必须在[mysqld]后面加入**
```
slow_query_log = on -- 开启日志;
slow_query_log_file = /data/f/mysql_slow_cw.log -- 记录日志的log文件; 注意:window上必须写绝对路径,比如 D:/wamp/bin/mysql/mysql5.5.16/data/show-slow.log
long_query_time = 2 -- 最长查询的秒数;
log-queries-not-using-indexes -- 表示记录没有使用索引的查询
```
## 5、使用慢查询
```
SELECT * FROM `emp` where ename like '%mQspyv%'; -- 1.163s
# Time: 150530 15:30:58 -- 该查询发生在2015-5-30 15:30:58
// 执行SQL的主机信息
# User@Host: root[root] @ localhost [127.0.0.1] -- 是谁,在什么主机上发生的查询
//SQL的执行信息
# Query_time: 1.134065 Lock_time: 0.000000 Rows_sent: 8 Rows_examined: 4000000
-- Query_time: 查询总共用了多少时间,Lock_time: 在查询时锁定表的时间,Rows_sent: 返回多少rows数据,Rows_examined: 表扫描了400W行数据才得到的结果;
//SQL执行事件
SET timestamp=1432971058; -- 发生慢查询时的时间戳;
// SQL的内容
SELECT * FROM `emp` where ename like '%mQspyv%';
```
开启慢查询后每天都有可能有好几G的慢查询日志,这个时候去人工的分析明显是不实际的;
## 6、慢查询日志分析工具之mysqldumpslow
该工具是慢查询自带的分析慢查询工具，一般只要安装了mysql，就会有该工具；
```
Usage: mysqldumpslow [ OPTS... ] [ LOGS... ] -- 后跟参数以及log文件的绝对地址;
-s, 是表示按照何种方式排序，
c、记录次数
t、时间
l、查询时间
r、返回的记录数
ac、at、al、ar，表示相应的倒叙；
-t, 是top n的意思，即为返回前面多少条的数据；
-g, 后边可以写一个正则匹配模式，大小写不敏感的；
```
**常见用法**
```
mysqldumpslow -s c -t 10 /var/run/mysqld/mysqld-slow.log # 取出使用最多的10条慢查询
mysqldumpslow -s t -t 3 /var/run/mysqld/mysqld-slow.log # 取出查询时间最慢的3条慢查询
mysqldumpslow -s t -t 10 -g “left join” /database/mysql/slow-log # 得到按照时间排序的前10条里面含有左连接的查询语句
mysqldumpslow -s r -t 10 -g 'left join' /var/run/mysqld/mysqld-slow.log # 按照扫描行数最多的
```
>注意: 使用mysqldumpslow的分析结果不会显示具体完整的sql语句,只会显示sql的组成结构;
假如: SELECT * FROM sms_send WHERE service_id=10 GROUP BY content LIMIT 0, 1000;
mysqldumpslow来显示
```
Count: 1 Time=1.91s (1s) Lock=0.00s (0s) Rows=1000.0 (1000), root[root]@[10.130.229.196]
SELECT * FROM sms_send WHERE service_id=N GROUP BY content LIMIT N, N;
Count:执行次数、Time:执行时间、Lock：锁定时间、ROWS：发送的行数、root：由那个服务器执行
SQL的具体内容
```
## 7、慢查询日志分析工具之pt-query-digest
pt-query-digest是用于分析mysql慢查询的一个工具，它可以分析binlog、General log、slowlog，也可以通过SHOWPROCESSLIST或者通过tcpdump抓取的MySQL协议数据来进行分析。可以把分析结果输出到文件中，分析过程是先对查询语句的条件进行参数化，然后对参数化以后的查询进行分组统计，统计出各查询的执行时间、次数、占比等，可以借助分析结果找出问题进行优化。
### 7.1、语法及重要选项
`pt-query-digest [OPTIONS] [FILES] [DSN]`
```
--create-review-table 当使用--review参数把分析结果输出到表中时，如果没有表就自动创建。
--create-history-table 当使用--history参数把分析结果输出到表中时，如果没有表就自动创建。
--filter 对输入的慢查询按指定的字符串进行匹配过滤后再进行分析
--limit限制输出结果百分比或数量，默认值是20,即将最慢的20条语句输出，如果是50%则按总响应时间占比从大到小排序，输出到总和达到50%位置截止。
--host mysql服务器地址
--user mysql用户名
--password mysql用户密码
--history 将分析结果保存到表中，分析结果比较详细，下次再使用--history时，如果存在相同的语句，且查询所在的时间区间和历史表中的不同，则会记录到数据表中，可以通过查询同一CHECKSUM来比较某类型查询的历史变化。
--review 将分析结果保存到表中，这个分析只是对查询条件进行参数化，一个类型的查询一条记录，比较简单。当下次使用--review时，如果存在相同的语句分析，就不会记录到数据表中。
--output 分析结果输出类型，值可以是report(标准分析报告)、slowlog(Mysql slow log)、json、json-anon，一般使用report，以便于阅读。
--since 从什么时间开始分析，值为字符串，可以是指定的某个”yyyy-mm-dd [hh:mm:ss]”格式的时间点，也可以是简单的一个时间值：s(秒)、h(小时)、m(分钟)、d(天)，如12h就表示从12小时前开始统计。
--until 截止时间，配合—since可以分析一段时间内的慢查询。
```
### 7.2、标准的分析报告解释
* 第一部分,总体统计结果;
```
Overall: 总共有多少条查询，上例为总共9100个查询。
unique: 唯一查询数量，即对查询条件进行参数化以后，总共有多少个不同的查询，该例为1170。
Time range: 查询执行的时间范围。
total: 总计 min:最小 max: 最大 avg:平均
95%: 把所有值从小到大排列，位置位于95%的那个数，这个数一般最具有参考价值。
median: 中位数，把所有值从小到大排列，位置位于中间那个数。
Exec time：总执行时间
Lock time:锁定事件
Rows sent：发送的行数
Rows examine：扫描的行数
Query size：
```
* 第二部分,查询分组统计结果;
由上图可见，这部分对查询进行参数化并分组，然后对各类查询的执行情况进行分析，结果按总执行时长，从大到小排序。
```
Response: 总的响应时间。
time: 该查询在本次分析中总的时间占比。
calls: 执行次数，即本次分析总共有多少条这种类型的查询语句。
R/Call: 平均每次执行的响应时间。
Item : 查询对象
```
* 第三部分,每一种查询的详细统计结果;
` pct：占用百分比`
由上图可见，25号查询的详细统计结果，最上面的表格列出了执行次数、最大、最小、平均、95%等各项目的统计。
```
Databases: 库名
Users: 各个用户执行的次数（占比）
Query\_time distribution : 查询时间分布, 长短体现区间占比，本例中1s-10s之间查询数量是10s以上的两倍。
Tables: 查询中涉及到的表
Explain: 示例
```
### 7.3、用法示例
(1)直接分析慢查询文件:
```
pt-query-digest slow.log > slow_report.log
```
(2)分析最近12小时内的查询：
```
pt-query-digest --since=12h slow.log > slow_report2.log
```
(3)分析指定时间范围内的查询：
```
pt-query-digest slow.log --since '2014-05-17 09:30:00' --until '2014-06-17 10:00:00'> > slow_report3.log
```
(4)分析只含有select语句的慢查询
```
pt-query-digest --filter '$event->{fingerprint} =~ m/^select/i' slow.log> slow_report4.log
```
(5) 针对某个用户的慢查询
```
pt-query-digest --filter '($event->{user} || "") =~ m/^root/i' slow.log> slow_report5.log
```
(6) 查询所有所有的全表扫描或full join的慢查询
```
pt-query-digest --filter '(($event->{Full_scan} || "") eq "yes") ||(($event->{Full_join} || "") eq "yes")' slow.log> slow_report6.log
```
(7)把查询保存到test数据库的query_review表,如果没有的话会自动创建;
```
pt-query-digest --user=root –password=abc123 --review h=localhost,D=test,t=query_review --create-review-table slow.log
```
(8)把查询保存到query_history表
```
pt-query-digest --user=root –password=abc123 --review h=localhost,D=test,t=query_ history --create-review-table slow.log_20140401
```
(9)通过tcpdump抓取mysql的tcp协议数据，然后再分析
```
tcpdump -s 65535 -x -nn -q -tttt -i any -c 1000 port 3306 > mysql.tcp.txt
pt-query-digest --type tcpdump mysql.tcp.txt> slow_report9.log
```
(10)分析binlog
```
mysqlbinlog mysql-bin.000093 > mysql-bin000093.sql
pt-query-digest --type=binlog mysql-bin000093.sql > slow_report10.log
```
(11)分析general log
```
pt-query-digest --type=genlog localhost.log > slow_report11.log
```
>另外,还有一款Query-digest-UI监控慢可视化查询应用，后续再玩；
## 8、如何通过慢查询日志发现有问题的SQL
* 查询次数多且每次查询占用时间长的SQL
* 通常为pt-query-digest分析的前几个查询
* 执行次数多，占用的百分比大
* IO大的SQL
* 注意pt-query-digest分析中的Rows examine项
* 扫描行数越多，IO消耗越大
* 未命中索引的SQL
* 注意pt-query-digest分析中Rows examine和Rows Send的对比
* Rows examine > Rows Send时，说明索引命中率不高
## 9、通过explain查询和分析SQL的执行计划
所谓索引就是为特定的mysql字段进行一些特定的算法排序,比如二叉树的算法和哈希算法,哈希算法是通过建立特征值,然后根据特征值来快速查找,而用的最多,并且是mysql默认的就是二叉树算法 BTREE,通过BTREE算法建立索引的字段,比如扫描20行就能得到未使用BTREE前扫描了2^20行的结果。
EXPLAIN可以帮助开发人员分析SQL问题,explain显示了mysql如何使用索引来处理select语句以及连接表,可以帮助选择更好的索引和写出更优化的查询语句.
**explain返回各列的含义**
* select_type：查询类型
* simple 简单select(不使用union或子查询)
* primary 最外面的select
* union union中的第二个或后面的select语句
* dependent union union中的第二个或后面的select语句,取决于外面的查询
* union result union的结果。
* subquery 子查询中的第一个select
* dependent subquery 子查询中的第一个select,取决于外面的查询
* derived 导出表的select(from子句的子查询)
* table：显示这一行的数据是关于哪张表的；
* type：这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为：
* const：常数查找，一般对主键或唯一索引。
* eq\_reg：范围查找，一般对主键或唯一索引。
* ref：连接查询，一个表是基于某一个索引的查找
* range：基于索引的范围查找
* index：索引的扫描
* ALL：表扫描
* possible\_keys：显示可能应用在这张表的索引。如果为空，没有可能的索引。
* key：实际使用的索引。如果为NULL，则没有使用索引。
* key\_len：使用的索引的长度。在不损失精确性的情况下，长度越短越好。
* ref：显示索引的哪一列被使用了，如果可能的话，是一个常数。
* rows：MYSQL认为必须检查的用来返回请求数据的行数。
* extra：扩展列，需要注意以下两个返回值。
* Using filesort：看到这个的时候，查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行
* Using temporary：看到这个的时候，查询需要优化了。这里，MYSQL需要创建一个临时表存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上。
## 7、Count（）和Max（）的优化
**查询最后支付时间-优化max\(\)函数**
* explain select max\(payment\_date\) from payment;
* 
* 如上图，该SQL进行全表扫描，共扫描了671行，由此可见效率不高。
* create index idx\_paydate on payment\(payment\_date\);
* 
* 由上图的 Select tables optimized away 可以看出它并不需要实际的查询表的数据，只需要通过索引就可以知道SQL的执行结果了。
**在一条SQL中同时查出2006年和2007年电影的数量--优化count\(\)函数**
* 错误的方式
* SELECT COUNT\(release\_year='2006' OR release\_year='2007'\) FROM film; 该计算会返回一列，无法分开计算2006和2007年的电影数量。
* 正确的方式
* SELECT COUNT\(release\_year='2006' OR NULL\) AS '2006年电影数量',COUNT\(release\_year='2007' OR NULL\) AS '2007年电影数量' FROM film；
* count\(\*\)和count\(id\)的区别
* count\(\*\)会统计所有行，包含NULL
* count\(id\) 的统计，不含NULL
## 8、子查询的优化
`通常情况下，需要把子查询优化为join查询，但在优化时要注意关联键是否有一对多的关系，要注意重复数据。`
## 9、group by的优化
* 优化前
```sql
explain SELECT actorfirst_name,actor.last_name,COUNT(*)
FROM sakila.film_actor
INNER JOIN sakila.actor USING(actor_id)
GROUP BY film_actor.actor_id;
```
* 优化后
```sql
explain SELECT actor.first_name,actor.last_name,c.cnt
FROM sakila.actor
INNER JOIN (
SELECT actor_id,COUNT(*) AS cnt
FROM sakila.film_actor GROUP BY actor_id
) AS c USING(actor_id);
```
## 10、Limit查询的优化
`limit常用于分页处理，时常会伴随order by从句使用，因此大多时候会使用Filesorts 这样会造成大量的IO问题`
* SELECT film\_id,description FROM sakila.film ORDER BY title LIMIT 50,5;
* 
* 如上图，该SQL进行了表扫描的操作，同时使用了文件排序的方式，因此在数据量非常大的情况下会产生大量的IO。
* 优化1：使用主键索引进行排序
```sql
SELECT film_id,description FROM sakila.film ORDER BY film_id LIMIT 50,5
```
* 
* 可以看出改写之后的SQL只扫描了55行。
* 优化2：记录上次返回的主键，在下次查询时使用主键过滤。
```sql
SELECT film_id,description FROM sakila.film WHERE film_id > 55 and film_id <=60 ORDER BY film_id LIMIT 1,5
```
* 
* 避免了数据量大时扫描过多的记录
* 缺点是，主键必须顺序排列。如果中间缺少，会出现过滤的记录不足5行的情况。
* 可以建立一个index\_id，保证此列是自增的，并加上索引。
