使用pt-query-digest分析mysql slow query log

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用系列 2核4GB
简介:

            使用pt-query-digest分析mysql slow query log


下载地址:

http://www.percona.com/software/percona-toolkit/

官方文档:

http://www.percona.com/doc/percona-toolkit/pt-query-digest.html


1,yum安装 ,先配置好 yum 源 

1
2
3
4
5
6
7
8
vim  /etc/yum .repos.d /percona .repo  
 
[percona]
name = CentOS $releasever - Percona
baseurl=http: //repo .percona.com /centos/ $releasever /os/ $basearch/
enabled = 1
gpgkey =  file : ///etc/pki/rpm-gpg/RPM-GPG-KEY-percona
gpgcheck = 0


2,开始安装:

1
yum  install  percona-toolkit -y


3,打开慢查询日志

请先确定在my.cnf中打开了mysql的slow_query_log,并且保证long_query_time参数设置得很合理。

1
2
3
4
vim  my.cnf
slow-query-log
slow-query-log- file  = slow.log
long-query- time  = 1


4,下载分析工具

pt-query-digest是一个perl脚本,只需下载即可

1
2
3
[arno.sun@srv-nc-ssh1 slowlog]$ wget percona.com /get/pt-query-digest 
[arno.sun@srv-nc-ssh1 slowlog]$  file  pt-query-digest pt-query-digest: a perl script text executable 
[arno.sun@srv-nc-ssh1 slowlog]$  chmod  +x pt-query-digest



5,使用:

直接上就行了,简单粗暴也没有问题。

事实上,这个工具确实有点简单粗暴,如果slow log够大的话,会消耗相当多的cpu和内存,所以最好把slow log和pt-query-digest放到其它的server上面运行。

pt-query-digest  slow.log > slow_report.log

分析结果解释说明:


第一部分是摘要:

cat slow_report.log


# 620ms user time, 10ms system time, 19.76M rss, 115.84M vsz

# Current date: Wed Mar 20 16:09:35 2013

# Hostname: srv-nc-ssh1                           

# Files: slow.log

# Overall: 371 total, 35 unique, 0.00 QPS, 0.05x concurrency _____________

# Time range: 2013-03-18 14:08:55 to 2013-03-19 12:23:36

# Attribute          total     min     max     avg     95%  stddev  median

# ============     ======= ======= ======= ======= ======= ======= =======

# Exec time          3959s      1s     73s     11s     37s     12s      7s

# Lock time           246s       0     42s   663ms   204us      4s    66us

# Rows sent         37.53M       0   6.10M 103.58k 485.50k 580.16k       0

# Rows examine      71.32M       0   6.10M 196.86k 961.27k 607.20k       0

# Rows affecte       1.03M       0 973.91k   2.83k    0.99  49.98k    0.99

# Rows read         37.53M       0   6.10M 103.58k 485.50k 580.16k       0

# Bytes sent         4.48G      14 383.55M  12.36M 101.56M  45.74M   13.83

# Tmp tables           110       0       5    0.30    0.99    0.79       0

# Tmp disk tbl          12       0       1    0.03       0    0.18       0

# Tmp tbl size      21.67M       0 1009.90k  59.82k 245.21k 158.04k      0

# Query size        71.10k      31     983  196.25  400.73  100.16  166.51


对于第一部分摘要的解释:

========================================================================================================

# 620ms user time, 10ms system time, 19.76M rss, 115.84M vsz

该工具执行日志分析的用户时间,系统时间,物理内存占用大小,虚拟内存占用大小。

# Hostname: srv-nc-ssh1  

运行分析工具的主机名

# Files: slow.log

被分析的文件名

# Overall: 371 total, 35 unique, 0.00 QPS, 0.05x concurrency _____________

语句总数量 (371),唯一的语句(35),Qps, 并发数

# Time range: 2013-03-18 14:08:55 to 2013-03-19 12:23:36

日志记录的时间范围

# Attribute          total     min     max     avg     95%  stddev  median


在这些值中,最有意义的恐怕就是95%了,与中位数类似,它也是把所有值从小到大排列,位置位于95%的那个数。

#Row sent            发送到客户端的行数

#Query size          查询的字符大小

========================================================================================================


继续看第二部分:



# Profile

# Rank Query ID           Response time   Calls R/Call  Apdx V/M   

Item# ==== ================== =============== ===== ======= ==== ===== =======

#    1 0x3BE81BF6A30F4C74 1702.9604 43.0%   182  9.3569 0.15  5.91 INSERT u_search_record

#    2 0x861AC23E20A17B65 1490.0836 37.6%    54 27.5941 0.05 13.54 SELECT UNION t_ask_price_info t_vouch_info t_cust_book t_hn_info

#    3 0xD43C719B4CE15C37   96.9039  2.4%    14  6.9217 0.11  1.42 SELECT u_car_info t_stas_auc_car

#    4 0x414D67056BE15CF4   58.2516  1.5%    20  2.9126 0.40  0.56 INSERT u_auction_back_cache

#    5 0x4A78E978D2543BCD   56.5418  1.4%     3 18.8473 0.00  3.14 SELECT t_cust_book

#    6 0x3A12FD01A8D9DA10   52.8541  1.3%     3 17.6180 0.00  0.00 SELECT t_auction_back_cache

#    7 0x9186BF39CBE58A0E   50.4508  1.3%     3 16.8169 0.00  0.01 SELECT t_check_result

#    8 0x68738A978FAB0D06   42.6112  1.1%     6  7.1019 0.17  4.66 SELECT t_sys_config t_hn_info t_hn_quote_list u_car_info

#    9 0x65EBDC4319D9955A   36.9794  0.9%     1 36.9794 0.00  0.00 INSERT SELECT t_hn_info t_hn_audit_quote

#   10 0x5203D60E3716D608   35.1022  0.9%     5  7.0204 0.00  0.05 SELECT mina_send

#   11 0x64C380BEB00DFB63   28.7720  0.7%    12  2.3977 0.50  0.40 SELECT u_vehicle_type

#   12 0xCDDA52E5A6B9F0B7   27.5927  0.7%     3  9.1976 0.00  0.00 SELECT rbvehicle

#   13 0xA5E766B81112B13A   27.5218  0.7%     4  6.8804 0.12  3.51 SELECT u_auction_back_cache

#   14 0x597A26236611758F   26.7460  0.7%     3  8.9153 0.00  0.65 SELECT t_hn_audit_quote t_ask_price_info

#   15 0x443D2230FC99811C   25.2928  0.6%     3  8.4309 0.00  0.00 SELECT t_hn_quote_list


Response: 总的响应时间。
time: 该查询在本次分析中总的时间占比。
calls: 执行次数,即本次分析总共有多少条这种类型的查询语句。
R/Call: 平均每次执行的响应时间。
Item : 查询对象

这一部分显示了最慢的十六种类型的SQL语句。

我这里最慢的是INSERT INTO u_search_record…… 共有182条语句,虽然每次插入的数据都是不同的,但也被归于同一类型的语句了。



第三部分最重要了。

以排名第一的SQL为例。



# Query 1: 0.00 QPS, 0.02x concurrency, ID 0x3BE81BF6A30F4C74 at byte 121216

# This item is included in the report because it matches --limit.

# Scores: Apdex = 0.15 [1.0], V/M = 5.91

# Query_time sparkline: |    


# Time range: 2013-03-18 15:53:08 to 2013-03-19 12:23:36


# Attribute    pct   total     min     max     avg     95%  stddev  median

# ============ === ======= ======= ======= ======= ======= ======= =======

# Count         49     182

# Exec time     43   1703s      1s     42s      9s     21s      7s      8s

# Lock time      0    12ms    41us   133us    64us    84us    15us    60us

# Rows sent      0       0       0       0       0       0       0       0

# Rows examine   0       0       0       0       0       0       0       0

# Rows affecte   0     182       1       1       1       1       0       1

# Rows read      0       0       0       0       0       0       0       0

# Bytes sent     0   2.49k      14      14      14      14       0      14

# Tmp tables     0       0       0       0       0       0       0       0

# Tmp disk tbl   0       0       0       0       0       0       0       0

# Tmp tbl size   0       0       0       0       0       0       0       0

# Query size    44  31.47k     166     291  177.04  192.76   24.93  158.58

# String:


# Databases    xinche

# Hosts


# InnoDB trxID 855383 (1/0%), 85538E (1/0%), 855391 (1/0%)... 179 more

# Last errno   0


# Users        carsingweb

# Query_time distribution

# 1us

# 10us

# 100us

# 1ms

# 10ms

# 100ms


#  1s   #################################################################  

#  10s+ #############################################

# Tables


# SHOW TABLE STATUS FROM `xinche` LIKE 'u_search_record'\G#    SHOW CREATE TABLE `xinche`.`u_search_record`\G

insert into u_search_record (ip, uri, params, create_date) values ('127.0.0.1', '/car/car!ajaxGetCarInfo.action', '[{"carinfo.id":["91202"]}]', '2013-03-18 17:17:08')\G



从上面可以看出,共有182条语句 

[95%]Exec time是21s,时间长得比较离谱了 

数据库为xinche,用户名为carsingweb 

然后是query time的分布图,这个图太恶心了,不过也可以看得出来大部分是处于1-10s之间的, 还有

一些超过10秒了。

最后是几条SQL语句, 是pt-query-digest生成的,这些语句有助于分析问题。

 




常见用法列表:


例(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-04-17 09:30:00' --until '2014-04-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)
把查询保存到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
pt-query-digest  --user=root –password=abc123--review  h=localhost,D=test,t=query_history--create-review-table  slow.log_20140402

(9)通过tcpdump抓取mysqltcp协议数据,然后再分析
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




官网资料

http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html






      本文转自crazy_charles 51CTO博客,原文链接:http://blog.51cto.com/douya/1597679,如需转载请自行联系原作者




相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
7天前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
本文介绍了MySQL InnoDB存储引擎中的数据文件和重做日志文件。数据文件包括`.ibd`和`ibdata`文件,用于存放InnoDB数据和索引。重做日志文件(redo log)确保数据的可靠性和事务的持久性,其大小和路径可由相关参数配置。文章还提供了视频讲解和示例代码。
112 11
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
|
1月前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1623 14
|
24天前
|
存储 关系型数据库 MySQL
基于案例分析 MySQL 权限认证中的具体优先原则
【10月更文挑战第26天】本文通过具体案例分析了MySQL权限认证中的优先原则,包括全局权限、数据库级别权限和表级别权限的设置与优先级。全局权限优先于数据库级别权限,后者又优先于表级别权限。在权限冲突时,更严格的权限将被优先执行,确保数据库的安全性与资源合理分配。
|
3天前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL的撤销日志文件和错误日志文件
本文介绍了MySQL的物理存储结构,重点讲解了InnoDB存储引擎中的撤销日志文件(undo log)和错误日志文件。从MySQL 8.0开始,默认生成两个10MB的undo表空间文件,并支持动态扩容和收缩。错误日志文件记录了MySQL启动、运行、关闭过程中的问题,通过示例展示了如何查看和使用这些日志。
|
25天前
|
存储 关系型数据库 MySQL
MySQL中的Redo Log、Undo Log和Binlog:深入解析
【10月更文挑战第21天】在数据库管理系统中,日志是保障数据一致性和完整性的关键机制。MySQL作为一种广泛使用的关系型数据库管理系统,提供了多种日志类型来满足不同的需求。本文将详细介绍MySQL中的Redo Log、Undo Log和Binlog,从背景、业务场景、功能、底层实现原理、使用措施等方面进行详细分析,并通过Java代码示例展示如何与这些日志进行交互。
49 0
|
11天前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
115 30
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
1月前
|
XML JSON Java
Logback 与 log4j2 性能对比:谁才是日志框架的性能王者?
【10月更文挑战第5天】在Java开发中,日志框架是不可或缺的工具,它们帮助我们记录系统运行时的信息、警告和错误,对于开发人员来说至关重要。在众多日志框架中,Logback和log4j2以其卓越的性能和丰富的功能脱颖而出,成为开发者们的首选。本文将深入探讨Logback与log4j2在性能方面的对比,通过详细的分析和实例,帮助大家理解两者之间的性能差异,以便在实际项目中做出更明智的选择。
216 3
|
3月前
|
Kubernetes Ubuntu Windows
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
【Azure K8S | AKS】分享从AKS集群的Node中查看日志的方法(/var/log)
131 3
|
1月前
|
Python
log日志学习
【10月更文挑战第9天】 python处理log打印模块log的使用和介绍
30 0
|
1月前
|
数据可视化
Tensorboard可视化学习笔记(一):如何可视化通过网页查看log日志
关于如何使用TensorBoard进行数据可视化的教程,包括TensorBoard的安装、配置环境变量、将数据写入TensorBoard、启动TensorBoard以及如何通过网页查看日志文件。
192 0