古人云：工欲善其事，必先利其器。作为一名优秀的mysql dba也需要有掌握几个好用的mysql管理工具，所以我也一直在整理和查找一些能够便于管理mysql的利器。以后的一段时间内，将会花一大部分的精力去搜索这些工具。
性能的管理一直都是摆在第一位的，dba的很多工作管理层都看不到也没有办法衡量价值，但是如果一个系统慢的跟蜗牛一样，dba通过监控调优把系统从崩溃边缘重新拉回到高铁时代。这种价值和触动应该是巨大的。（很多企业的领导认为系统跑不动了就需要换更快的CPU、更大的内存、更快的存储，而且这还不是少数，所以DBA的价值也一直体现不出来，薪水自然也就不会很高）
mysql的日志是跟踪mysql性能瓶颈的最快和最直接的方式了，系统性能出现瓶颈的时候，首先要打开慢查询日志，进行跟踪；这段时间关于慢查询日志的管理和查看已经整理过两篇文章了，不经意间又发现了一个查看慢查询日志的工具：mk-query-digest，这个工具网上号称mysql dba必须掌握的十大工具之首。
以下是软件的介绍：
1、软件的安装,下载地址：http://www.percona.com/downloads/percona-toolkit/
2、链接：http://pan.baidu.com/s/1i35Ufxr 密码：ybtm
2、软件的使用，pt-query-digest --help
Usage: pt-query-digest [OPTIONS] [FILES] [DSN]
常用的查询语句：
- pt-query-digest JOEONE-IPOSDS-SLOW.LOG> JOEONE-IPOSDS-SLOW1.log 把当前的结果输出到文件slow_report.log
- pt-query-digest --since=24h JOEONE-IPOSDS-SLOW.LOG > slow_report2.log 分析最近24小时的结果
- pt-query-digest --since ‘2015-01-09 09:30:00‘ --until ‘2015-02-01 09:30:00‘ JOEONE-IPOSDS-SLOW.LOG> slow_report3.log 分析规定时间段的结果
- pt-query-digest --filter ‘(($event->{Full_scan} || "") eq "yes") ||(($event->{Full_join} || "") eq "yes")‘ JOEONE-IPOSDS-SLOW.LOG> slow_report6.log 所有的全表扫描或full join的慢查询
加入参数create-review-table，可以把结果写到mysql的表中
pt-query-digest --user=root --password=123456 --review h=localhost,D=test,t=query_table --create-review-table JOEONE-IPOSDS-SLOW.LOG
3、分析结果的查看
慢查询日志的结果可以分为三个部分：整体的概要、总体的sql语句、每条sql语句的详细情况
3.1 整体的概要
|
# 21.9s user time, 80ms system time, 95.84M rss, 270.52M vsz
# Current date: Tue Feb 10 00:47:57 2015
# Hostname: DBR-T01 主机名称
# Files: /data/IPOSDS-SLOW.LOG 慢日志文件
# Overall: 27.94k total, 181 unique, 0.01 QPS, 0.19x concurrency
# Time range: 2015-01-07 05:31:12 to 2015-02-09 13:02:08 结果的时间范围
# Attribute total min max avg 95% stddev median
# ============ ======= ======= ======= ======= ======= ======= =======
# Exec time 553798s 10s 1829s 20s 33s 23s 16s
# Lock time 469s 0 34s 17ms 332us 474ms 144us
# Rows sent 5.92G 0 19.10M 222.29k 2.16k 1.34M 0
# Rows examine 282.33G 0 618.66M 10.35M 11.87M 9.62M 11.87M
# Query size 55.39M 17 781.03k 2.03k 487.09 33.70k 363.48 |
上面摘要显示/data/IPOSDS-SLOW.LOG中共有27940次SQL语句（27.94k），其中181条跳语句是不重复的；
Exec time总时间表示这些SQL的总体运行时间，这部分时间参考Time range，可以大概知道系统的压力情况；
Lock time 显示锁的时间，太长的锁等待，说明程序设计有问题；
Rows sent 发送客户端的行数
Rows examine 表示扫描的行数，Rows examine和Rows sent的比值，可以初步判断索引的选择性问题；
Query size：查询语句的字符数
以上的那些数值主要参考95%的数据平均结果；
3.2 语句整体概况
|
# Profile
# Rank Query ID Response time Calls R/Call V/M Item
# ==== ================== ================= ===== ======= ===== ==========
# 1 0xB6CE88A271A1C8C5 303925.9823 54.9% 17430 17.4369 1.36 UPDATE SELECT spkcb com_base_guige? com_base_shangpin com_base_kehu
# 2 0x67A347A2812914DF 69120.9420 12.5% 1306 52.9257 88.15 SELECT pdrwdmx
# 3 0xABB9B3395E22262F 20962.6758 3.8% 1180 17.7650 1.63 UPDATE qtlsdtj
# 4 0x6CB2B38E9A6BA060 20712.8072 3.7% 1438 14.4039 7.20 SHOW TABLE STATUS
# 5 0xE07B65EBB8252150 19329.7730 3.5% 896 21.5734 6.36 SELECT qtlsd
# 6 0xB95D3B1113D55B10 16386.1202 3.0% 1178 13.9101 7.74 SELECT qtlsdmx
# 7 0x2D709387799372B6 13340.1712 2.4% 229 58.2540 35... UPDATE zdjhd zdjhdtj
# 8 0x5F21295B4F65ADA4 12898.3620 2.3% 906 14.2366 1.03 INSERT UPDATE spkcb
# 9 0x35B910EAB55A5C9C 8953.4060 1.6% 243 36.8453 9.91 SELECT UNION pdzb_?_?_? zdpdd zdpddmx
# 10 0xEAD308EC0677AB59 7974.1363 1.4% 385 20.7120 4.76 INSERT SELECT UNION SELECT UNION SELECT UNION
# 11 0x54AA6A3907264713 7388.4440 1.3% 619 11.9361 0.32 SELECT qtlsd
# 12 0x223C39F84004B5A3 6455.4302 1.2% 266 24.2685 47.24 SELECT qtlsd
# 13 0x2F7AD31185241551 6034.4285 1.1% 142 42.4960 3.74 UPDATE ckkw cangku
# 14 0xD657E241B398C447 5546.4095 1.0% 145 38.2511 12.98 SELECT UNION pdzb_?_?_? zdpdd zdpddmx
# 15 0xC4BF8AE027FAD479 3976.7995 0.7% 72 55.2333 6.44 DELETE SELECT qdtjdmx qdtjd
# 16 0xA5288845FB6A8036 3817.4887 0.7% 274 13.9324 0.83 INSERT SELECT UPDATE spkcb zdjhdmx zdjhd |
--Rank:分析的所有查询语句的排名，默认按查询时间降序排序，可以通过--order-by指定排序方式
--Query ID：查询语句的指纹，去掉了多余空格、和文本字符
--Response time：响应时间，占所有响应时间的百分比 （UPDATE SELECT spkcb com_base_guige? com_base_shangpin com_base_kehu这条语句占用了54.9%的时间，首要调优对象）
--Calls：查询执行的次数
--R/Call：每次执行的平均响应时间
--V/M：响应时间Variance-to-mean的比率
--Item：查询语句
--最后一行没有包括在报告中的查询合计统计信息，如使用了选项--limit和—outliers
第三部分，详细的执行语句
|
# Query 1: 0.01 QPS, 0.19x concurrency, ID 0xB6CE88A271A1C8C5 at byte 37907885 （Query 1按照第二部分的顺序进行排序）
# This item is included in the report because it matches --limit.
# Scores: V/M = 1.36
# Time range: 2015-01-08 00:02:19 to 2015-01-26 08:38:49
# Attribute pct total min max avg 95% stddev median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count 62 17430 （pct 占总数的比例，total运行的总次数，17430/27940=62%）
# Exec time 54 303926s 10s 175s 17s 24s 5s 16s （运行时间的分布）
# Lock time 2 10s 74us 896ms 551us 247us 12ms 159us
# Rows sent 0 0 0 0 0 0 0 0
# Rows examine 72 204.54G 4.57M 12.15M 12.02M 11.87M 144.66k 11.87M （从这边可以看出，扫描的行数很多）
# Query size 10 6.05M 361 365 364.09 363.48 0.67 363.48
# String:
# Databases ipos （数据库名称）
# Hosts 192.168.0.10 （服务器主机名）
# Users root
# Query_time distribution
# 1us
# 10us
# 100us
# 1ms
# 10ms
# 100ms
# 1s
# 10s+ #######################这个语句涉及到的表名称###############################
# Tables
# SHOW TABLE STATUS FROM `ipos` LIKE ‘ipos_spkcb‘\G
# SHOW CREATE TABLE `ipos`.`ipos_spkcb`\G
# SHOW TABLE STATUS FROM `ipos` LIKE ‘com_base_guige1‘\G
# SHOW CREATE TABLE `ipos`.`com_base_guige1`\G
# SHOW TABLE STATUS FROM `ipos` LIKE ‘com_base_guige2‘\G
# SHOW CREATE TABLE `ipos`.`com_base_guige2`\G
# SHOW TABLE STATUS FROM `ipos` LIKE ‘com_base_shangpin‘\G
# SHOW CREATE TABLE `ipos`.`com_base_shangpin`\G
# SHOW TABLE STATUS FROM `ipos` LIKE ‘com_base_kehu‘\G
# SHOW CREATE TABLE `ipos`.`com_base_kehu`\G
###############################完整的SQL语句#############################################
Update ipos_spkcb a
Set
gg1_id=(Select id From com_base_guige1 gg1 Where gg1.ggdm = a.gg1dm limit 1 ),
gg2_id=(Select id From com_base_guige2 gg2 Where gg2.ggdm = a.gg2dm limit 1 ),
sp_id = (Select id From com_base_shangpin sp Where sp.spdm = a.spdm),
zd_id = (Select id From com_base_kehu kh Where kh.khdm = a.drp_ckdm)
Where drp_mid= ‘CDA07AJB1441321015A‘\G |
通过以上分析，再运行explain可以查看这个语句的执行计划；
总结：pt-query-digest语句给出的报告，相对于前面的2种方式，已经有了明显的改进，最主要体现在可以从宏观去看每条语句对系统的影响情况；
相信根据步骤分析了整个慢日志文件后，应该可以知道，哪种类型的语句、那种几条语句消耗了性能，这些语句是突发的还是平时运行都是这种情况的。
通过查看这些表的结构和语句的执行计划后，可以进行相应的调优；
........................................................................................................................................................................
本文作者：JOHN，某上市公司DBA，业余时间专注于数据库的技术管理，从管理的角度去运用技术。
ORACLE技术博客：ORACLE 猎人笔记 数据库技术群：367875324 （请备注ORACLE管理 ）
........................................................................................................................................................................
mysql 必须掌握的工具pt-query-digest
原文：http://blog.itpub.net/12679300/viewspace-1432446/
