精华内容
下载资源
问答
  • 主要介绍了关于MySQL慢查询之pt-query-digest分析慢查询日志的相关资料,文中介绍的非常详细,对大家具有一定的参考价值,需要的朋友们下面来一起看看吧。
  • 60-200-072-使用-命令-MySQL使用mysqldumpslow分析慢查询日志文件.pdf
  • 使用工具分析慢查询日志

    千次阅读 2018-06-24 13:39:30
    Query_time、Rows_examined、Rows_sent这3个信息让我们看到了查询需要...但在一个高并发的数据库服务上,或者在做压力测试时,如果发现慢查询日志增长得非常快,很难筛选和查找里面的信息,那么在这种情况下,有如...

    Query_time、Rows_examined、Rows_sent这3个信息让我们看到了查询需要优化什么。查询时间最长的SQL往往是最需要优化的,如果检查了大量记录(Rows_examined),而只返回很小的结果集(Rows_sent),往往也意味着存在不良SQL。但在一个高并发的数据库服务上,或者在做压力测试时,如果发现慢查询日志增长得非常快,很难筛选和查找里面的信息,那么在这种情况下,有如下两种选择。

    调整阈值,先设置为较大的阈值,这样慢查询记录就很少了,等优化得差不多了,再减少阈值,不断进行优化。

    使用命令/脚本、工具进行分析,如mysqldumpslow、pt-query-digest等。

    第一种方法比较繁琐,建议大家使用第二种方法。如果优化效果比较理想,希望更进一步调优,则可以减低阈值,然后记录更多的慢查询日志,然后继续使用脚本、工具进行分析。

    1.使用操作系统命令分析
    可以使用操作系统自带的命令进行一些简单的统计,如grep、awk、wc,但不容易实现更高级的筛选排序。

    下面来看个示例,通过如下命令可以看到每秒的慢查询的统计,当检查到有突变时,往往会有异常发生,这时便可以更进   

    一步到具体的慢查询日志里去查找可能的原因。

    awk'/^# Time:/{print $3, $4, c;c=0}/^# User/{c++}' /var/lib/mysql/service1-slow.log> /tmp/aaa.log

    2.mysqldumpslow

    mysqldumpslow命令是官方自带的,此命令可获得日志中的查询摘要。

    以下是mysqldumpslow命令的使用示例。

    访问时间最长的10个sql语句的命令如下。

    mysqldumpslow -t10/var/lib/mysql/service1-slow.log

    访问次数最多的10个sql语句的命令如下。

    mysqldumpslow -s c -t10/var/lib/mysql/service1-slow.log

    访问记录集最多的10个sql语句的命令如下。

    mysqldumpslow-s r -t10 /var/lib/mysql/service1-slow.log

     

    试验过程如下:

    [root@service1~]# mysql -uroot -p

    Enterpassword:

    Welcometo the MySQL monitor.  Commands end with; or \g.

    YourMySQL connection id is 6

    Serverversion: 5.7.22-log MySQL Community Server (GPL)

     

    Copyright(c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

     

    Oracleis a registered trademark of Oracle Corporation and/or its

    affiliates.Other names may be trademarks of their respective

    owners.

     

    Type'help;' or '\h' for help. Type '\c' to clear the current input statement.

     

    mysql>show variables like 'slow_query%';

    +---------------------+----------------------------------+

    |Variable_name       | Value                            |

    +---------------------+----------------------------------+

    |slow_query_log      | OFF                              |

    |slow_query_log_file | /var/lib/mysql/service1-slow.log |

    +---------------------+----------------------------------+

    2rows in set (0.03 sec)

     

    mysql>set global slow_query_log=1;

    QueryOK, 0 rows affected (0.00 sec)

     

    mysql>set global long_query_time=1;

    QueryOK, 0 rows affected (0.00 sec)

     

    mysql>show variables like 'slow_query%';

    +---------------------+----------------------------------+

    |Variable_name       | Value                            |

    +---------------------+----------------------------------+

    |slow_query_log      | ON                               |

    |slow_query_log_file | /var/lib/mysql/service1-slow.log |

    +---------------------+----------------------------------+

    2rows in set (0.00 sec)

     

    mysql>select sleep(2);

    +----------+

    |sleep(2) |

    +----------+

    |        0 |

    +----------+

    1row in set (2.01 sec)

     

    在同一个session执行select sleep(2);在慢查询日志不起作用,换一个session,执行如下:

    mysql>select sleep(2);

    +----------+

    |sleep(2) |

    +----------+

    |        0 |

    +----------+

    1row in set (2.00 sec)

     

    换一个session,执行如下:

    [root@service1~]# mysqldumpslow -t 10 /var/lib/mysql/service1-slow.log

     

    Readingmysql slow query log from /var/lib/mysql/service1-slow.log

    Count:1  Time=2.00s (2s)  Lock=0.00s (0s)  Rows=1.0 (1), root[root]@localhost

      select sleep(N)

     

    Count:1  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=0.0 (0), 0users@0hosts

     

     

    Diedat /usr/bin/mysqldumpslow line 161, <> chunk 1.

    3.pt-query-digest

    有一些第三方分析工具(如msyqlslapt-query-digest)比mysqldumpslow更强大,更友好。以下将重点介绍pt-query-digest工具。

    pt-query-digest可以生成一份比官方mysqldumpslow可读性好得多的报告。安装也很简单,命令如下。

    wget www.percona.com/get/pt-query-digest

    chmod u+x pt-query-digest

    我是如下操作的(linux当时无法上网):在/usr/bin/ 目下vi vipt-query-digest,www.percona.com/get/pt-query-digest内容粘贴过来,然后执行chmod u+x pt-query-digest即可。

    基本语法格式如下所示。

    pt-query-digest [OPTIONS] [FILES] [DSN]

    详细的语法介绍,请参考16.2.2节,这里仅给出一些常用的示例。

    直接分析慢查询的命令如下。

     [root@service1 bin]# pt-query-digest/var/lib/mysql/service1-slow.log > /root/service1-slow.rtf

    分析半个小时内的慢查询的命令如下。

    pt-query-digest --since 1800s /path/of/slow.log >slow.rtf

    分析一段时间范围内的慢查询的命令如下。

    pt-query-digest --since '2014-04-14 22:00:00' --until'2014-04-14 23:00:00' /path/of/slow.log > slow.rtf

    显示所有分析的查询命令如下。

    pt-query-digest --limit 100% /path/of/slow.log >slow.rtf

    其中,“--limit”参数默认是“95%:20”,表示显示95%的最差的查询,或者20个最差的查询。

    此外,也可以用这个工具来分析二进志日志,以查看我们日常的修改语句是如何分布的,首先需要把二进志日志转换为文

    本格式。

    mysqlbinlog mysql-bin.012639 > /tmp/012639.log

    pt-query-digest --type binlog /tmp/012639.log

    对于以上分析命令,同样可以加上参数筛选信息,如“--since”、“--until”。

    那么,如何查看pt-query-digest报告呢?

    以下是一个输出报告,为了节省篇幅,删除了部分信息。

    # 140.9s user time, 1.4s system time, 57.93M rss, 154.03Mvsz

    # Current date: Sun Feb 16 09:16:39 2011

    解释:执行pt-query-digest工具的时间。

    # Files: /usr/lcoal/mysql/data/slowquery.log

    # Overall: 304.88k total, 159 unique, 0.22 QPS, 0.15xconcurrency ________

    解释:慢查询次数一共是304.88k,唯一的查询159个。

    # Time range: 2010-12-01 00:00:01 to 2010-12-17 09:05:17

    解释:这里记录的是发现第一条慢查询的时间到最后一条慢查询的时间。

    # Attribute total min max avg 95% stddev median

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

    # Exec time 216112s 500ms 21s 709ms 1s 968ms 552ms

    # Lock time 414s 21us 101ms 1ms 626us 7ms 84us

    # Rows sent 169.69M 0 213.73k 583.60 97.36 10.75k 9.83

    # Rows examine 60.26G 0 866.23k 207.25k 328.61k 70.68k201.74k

    # Query size 120.31M 35 21.07k 413.76 719.66 148.97363.48

    解释分别如下。

    ·Exec time:执行时间。

    ·Lock time:表锁的时间。

    ·Rows sent:返回的结果集记录数。

    ·Rows examine:实际扫描的记录数。

    ·Query size:应用和数据库交互的查询文本大小。

    # Profile

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

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

    # 1 0x5931CCE8168ECE59 92062.4390 42.6% 168672 0.54581.00 0.01 SELECT game_info game_stat

    # 2 0x0E8691F18411F3DC 23404.4270 10.8% 18602 1.2582 0.600.04 SELECT game_info game_stat game_info_2

    ...

    ...

    解释分别如下。

    ·Rank:所有查询日志分析完毕后,此查询的排序。

    ·Query ID:查询的标识字符串。

    ·Response time:总的响应时间,以及总占比。一般小于5%可以不用关注。

    ·Calls:查询被调用执行的次数。

    ·R/Call:每次执行的平均响应时间。

    ·Apdx:应用程序的性能指数得分。(Apdex响应的时间越长,得分越低。)

    ·V/M:响应时间的方差均值比(变异数对平均数比,变异系数)。可说明样本的分散程度,这个值越大,往往是越值得考

    虑优化的对象。

    ·Item:查询的简单显示,包括查询的类型和所涉及的表。

    以下将按默认的响应时间进行排序,并列出TOP n条查询。并且pt-query-digest输出了EXPLAIN的语句,以方便我们验证查

    询计划。

    # Query 1: 0.12 QPS, 0.07x concurrency, ID0x5931CCE8168ECE59 at byte 243208985

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

    # Scores: Apdex = 1.00 [1.0], V/M = 0.01

    # Query_time sparkline: | ^__|

    # Time range: 2010-12-01 00:00:01 to 2010-12-17 09:04:53

    # Attribute pct total min max avg 95% stddev median

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

    # Count 55 168672

    # Exec time 42 92062s 500ms 11s 546ms 640ms 77ms 501ms

    # Lock time 68 283s 58us 101ms 2ms 690us 8ms 80us

    # Rows sent 1 2.04M 10 100 12.67 9.83 14.86 9.83

    # Rows examine 54 33.12G 204.96k 208.16k 205.90k 201.74k0.00 201.74k

    # Query size 50 60.64M 376 378 376.97 363.48 0 363.48

    # String:

    # Hosts

    # Users sd_game

    # Query_time distribution

    # 1us

    # 10us

    # 100us

    # 1ms

    # 10ms

    # 100ms################################################################

    # 1s #

    # 10s+ #

    # Tables

    # SHOW TABLE STATUS LIKE 'game_info'\G

    # SHOW CREATE TABLE 'game_info'\G

    # SHOW TABLE STATUS LIKE 'game_stat'\G

    # SHOW CREATE TABLE 'game_stat'\G

    # EXPLAIN /*!50100 PARTITIONS*/

    select ...

    以上关于SELECT查询的具体文本此处省略。

    从pt-query-digest工具中看到的信息里,对于响应时间,不仅需要关注平均值,还需要关注百分比响应,以及关注其的分布情况和离散程度。

    对于响应时间的方差均值比,如果该均值比很大,则可能意味着有一些异常值。

    慢查询日志里的慢查询不一定就是BAD SQL。可能是受到了其他查询的影响,或者是受系统资源限制所导致的。有了分析报告,就可以用EXPLAIN工具确认慢查询的执行计划,从而进行调优。通常,80%的问题是因为索引不佳而引起的,添加适当的索引即可。

    展开全文
  • pt-query-digest 分析慢查询日志

    千次阅读 2021-03-12 11:22:05
    pt-query-digest是用于分析mysql慢查询的一个工具,它可以分析binlog、General log、slowlog,也可以通过SHOWPROCESSLIST或者通过tcpdump抓取的MySQL协议数据来进行分析。可以把分析结果输出到文件中,分析过程是先...

    一、简介

    pt-query-digest是用于分析mysql慢查询的一个工具,它可以分析binlog、General log、slowlog,也可以通过SHOWPROCESSLIST或者通过tcpdump抓取的MySQL协议数据来进行分析。可以把分析结果输出到文件中,分析过程是先对查询语句的条件进行参数化,然后对参数化以后的查询进行分组统计,统计出各查询的执行时间、次数、占比等,可以借助分析结果找出问题进行优化。

    二、安装pt-query-digest

    1.下载页面:https://www.percona.com/doc/percona-toolkit/2.2/installation.html
    2.perl的模块

    yum install -y perl-CPAN perl-Time-HiRes perl-Digest-MD5 (如果没有这个拓展,会报 Can't locate Digest/MD5.pm)

    3.安装步骤
    方法一:rpm安装

    cd /usr/local/src
    wget percona.com/get/percona-toolkit.rpm
    yum install -y percona-toolkit.rpm

    工具安装目录在:/usr/bin

    方法二:源码安装

    cd /usr/local/src
    wget percona.com/get/percona-toolkit.tar.gz
    tar zxf percona-toolkit.tar.gz
    cd percona-toolkit-2.2.19
    perl Makefile.PL PREFIX=/usr/local/percona-toolkit
    make && make install

    工具安装目录在:/usr/local/percona-toolkit/bin

    4.各工具用法简介(详细内容:https://www.percona.com/doc/percona-toolkit/2.2/index.html
    (1)慢查询日志分析统计

    pt-query-digest /usr/local/mysql/data/slow.log

    (2)服务器摘要

    pt-summary 

    (3)服务器磁盘监测

    pt-diskstats 

    (4)mysql服务状态摘要

    pt-mysql-summary -- --user=root --password=root 

    三、pt-query-digest语法及重要选项

     

    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可以分析一段时间内的慢查询。

     

    四、分析pt-query-digest输出结果

    第一部分:总体统计结果
    Overall:总共有多少条查询
    Time range:查询执行的时间范围
    unique:唯一查询数量,即对查询条件进行参数化以后,总共有多少个不同的查询
    total:总计   min:最小   max:最大  avg:平均
    95%:把所有值从小到大排列,位置位于95%的那个数,这个数一般最具有参考价值
    median:中位数,把所有值从小到大排列,位置位于中间那个数

     

    # 该工具执行日志分析的用户时间,系统时间,物理内存占用大小,虚拟内存占用大小
    # 340ms user time, 140ms system time, 23.99M rss, 203.11M vsz
    # 工具执行时间
    # Current date: Fri Nov 25 02:37:18 2016
    # 运行分析工具的主机名
    # Hostname: localhost.localdomain
    # 被分析的文件名
    # Files: slow.log
    # 语句总数量,唯一的语句数量,QPS,并发数
    # Overall: 2 total, 2 unique, 0.01 QPS, 0.01x concurrency ________________
    # 日志记录的时间范围
    # Time range: 2016-11-22 06:06:18 to 06:11:40
    # 属性               总计      最小    最大    平均    95%  标准    中等
    # Attribute          total     min     max     avg     95%  stddev  median
    # ============     ======= ======= ======= ======= ======= ======= =======
    # 语句执行时间
    # Exec time             3s   640ms      2s      1s      2s   999ms      1s
    # 锁占用时间
    # Lock time            1ms       0     1ms   723us     1ms     1ms   723us
    # 发送到客户端的行数
    # Rows sent              5       1       4    2.50       4    2.12    2.50
    # select语句扫描行数
    # Rows examine     186.17k       0 186.17k  93.09k 186.17k 131.64k  93.09k
    # 查询的字符数
    # Query size           455      15     440  227.50     440  300.52  227.50

     

    第二部分:查询分组统计结果
    Rank:所有语句的排名,默认按查询时间降序排列,通过--order-by指定
    Query ID:语句的ID,(去掉多余空格和文本字符,计算hash值)
    Response:总的响应时间
    time:该查询在本次分析中总的时间占比
    calls:执行次数,即本次分析总共有多少条这种类型的查询语句
    R/Call:平均每次执行的响应时间
    V/M:响应时间Variance-to-mean的比率
    Item:查询对象

    # Profile
    # Rank Query ID           Response time Calls R/Call V/M   Item
    # ==== ================== ============= ===== ====== ===== ===============
    #    1 0xF9A57DD5A41825CA  2.0529 76.2%     1 2.0529  0.00 SELECT
    #    2 0x4194D8F83F4F9365  0.6401 23.8%     1 0.6401  0.00 SELECT wx_member_base

    第三部分:每一种查询的详细统计结果
    由下面查询的详细统计结果,最上面的表格列出了执行次数、最大、最小、平均、95%等各项目的统计。
    ID:查询的ID号,和上图的Query ID对应
    Databases:数据库名
    Users:各个用户执行的次数(占比)
    Query_time distribution :查询时间分布, 长短体现区间占比,本例中1s-10s之间查询数量是10s以上的两倍。
    Tables:查询中涉及到的表
    Explain:SQL语句

     

    # Query 1: 0 QPS, 0x concurrency, ID 0xF9A57DD5A41825CA at byte 802 ______
    # This item is included in the report because it matches --limit.
    # Scores: V/M = 0.00
    # Time range: all events occurred at 2016-11-22 06:11:40
    # Attribute    pct   total     min     max     avg     95%  stddev  median
    # ============ === ======= ======= ======= ======= ======= ======= =======
    # Count         50       1
    # Exec time     76      2s      2s      2s      2s      2s       0      2s
    # Lock time      0       0       0       0       0       0       0       0
    # Rows sent     20       1       1       1       1       1       0       1
    # Rows examine   0       0       0       0       0       0       0       0
    # Query size     3      15      15      15      15      15       0      15
    # String:
    # Databases    test
    # Hosts        192.168.8.1
    # Users        mysql
    # Query_time distribution
    #   1us
    #  10us
    # 100us
    #   1ms
    #  10ms
    # 100ms
    #    1s  ################################################################
    #  10s+
    # EXPLAIN /*!50100 PARTITIONS*/
    select sleep(2)\G

     

    五、用法示例

    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 '2017-01-07 09:30:00' --until '2017-01-07 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_0001
    pt-query-digest  --user=root –password=abc123 --review  h=localhost,D=test,t=query_history--create-review-table  slow.log_0002

    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
    展开全文
  •  pt-query-digest可以从普通MySQL日志慢查询日志以及二进制日志分析查询,甚至可以从SHOW PROCESSLIST和MySQL协议的tcpdump中进行分析,如果没有指定文件,它从标准输入流(STDIN)中读取数据。

      ORACLE数据库可利用awr报告来查找top sql,其实mysql中,我们可以利用pt-query-digest工具来查找时间最长的TOP SQL。
      pt-query-digest可以从普通MySQL日志,慢查询日志以及二进制日志中分析查询,甚至可以从SHOW PROCESSLIST和MySQL协议的tcpdump中进行分析,如果没有指定文件,它从标准输入流(STDIN)中读取数据。
    [apps@mvxl0782 bin]$ pwd
    /apps/tool/percona-toolkit-2.2.10/bin
    [apps@mvxl0782 bin]$ ./pt-query-digest /apps/logs/mysql/slow3306.log

    整个输出分为三大部分:

    1、整体概要(Overall)

    # 8.9s user time, 50ms system time, 25.92M rss, 200.46M vsz
    # Current date: Mon Jul 25 21:50:47 2016
    # Hostname: mvxl0782
    # Files: /apps/logs/mysql/slow3306.log
    # Overall: 23.07k total, 11 unique, 0.30 QPS, 0.73x concurrency __________
    # Time range: 2016-07-25 00:00:07 to 21:35:16
    # Attribute          total     min     max     avg     95%  stddev  median
    # ============     ======= ======= ======= ======= ======= ======= =======
    # Exec time         56524s      1s    427s      2s     13s      5s      1s
    # Lock time             2s    13us   791us   106us   176us    47us   103us
    # Rows sent        213.29M       0  67.42M   9.47k    0.99 577.32k       0
    # Rows examine      17.23G   2.79k  67.42M 783.39k  11.87M   2.66M  23.58k
    # Merge passes           0       0       0       0       0       0       0
    # Query size        12.67M      55   2.21k  576.00   1.78k  317.16  487.09
    # Boolean:
    # Full join     94% yes,   5% no
    # Full scan     99% yes,   0% no
    # Tmp table     99% yes,   0% no

    这个部分是一个大致的概要信息(类似loadrunner给出的概要信息),通过它可以对当前MySQL的查询性能做一个初步的评估,比如各个指标的最大值(max),平均值(min),95%分布值,中位数(median),标准偏差(stddev)。这些指标有查询的执行时间(Exec time),锁占用的时间(Lock time),MySQL执行器需要检查的行数(Rows examine),最后返回给客户端的行数(Rows sent),查询的大小。

    2、查询的汇总信息(Profile)

    # Profile
    # Rank Query ID           Response time    Calls R/Call  V/M   Item
    # ==== ================== ================ ===== ======= ===== ===========
    #    1 0x6B78B35582099676 24511.3273 43.4% 16194  1.5136  0.01 SELECT t_wo_message_log

    t_work_order t_wo_message_log t_work_order
    #    2 0xBAD5151487742A30 15576.7264 27.6%   910 17.1173 0.08 SELECT UNION t_order

    t_tracking_log t_carrier_mapping t_order t_order_carrier t_tracking_log t_carrier_mapping
    #    3 0x876A6CCFDEC46DBF  7594.0775 13.4%  5119  1.4835  0.00 SELECT t_wo_message_log

    t_work_order t_wo_message_log t_work_order
    #    4 0x28CFDDB4F8E96817  4457.6805  7.9%   260 17.1449  0.05 SELECT UNION t_order

    t_tracking_log t_carrier_mapping t_order t_order_carrier t_tracking_log t_carrier_mapping
    #    5 0x98AC2C95196539D6  2395.4859  4.2%   260  9.2134  0.01 SELECT t_order t_carrier_mapping

    t_logistics_tranlog t_order_tracking
    #    6 0x67A347A2812914DF  1528.9402  2.7%    17 89.9377 11... SELECT lots.t_order_tracking
    #    7 0x86526DA43DDE0291   359.9037  0.6%   258  1.3950  0.01 SELECT t_order t_carrier_mapping

    t_carrier_tracking t_logistics_tranlog
    #    8 0xC73FF1C974FD7463    57.4173  0.1%    43  1.3353  0.00 UPDATE t_order t_order_cancel_log
    # MISC 0xMISC                42.5195  0.1%     8  5.3149   0.0 <3 ITEMS>
    每个查询都有一个Query ID,这个ID通过Hash计算出来的。pt-query-digest是根据这个所谓的Fingerprint来group by的。上面标红色部分是单次执行时间最长的TOP SQL,需要重点关注优化。

    Rank整个分析中该“语句”的排名,一般也就是性能最常的。
    Response time  “语句”的响应时间以及整体占比情况。
    Calls 该“语句”的执行次数。
    R/Call 每次执行的平均响应时间。
    V/M 响应时间的差异平均对比率。
    在尾部有一行输出,显示了其他2个占比较低而不值得单独显示的查询的统计数据。

    3、详细信息

    这个部分会列出Profile表中每个查询的详细信息:

    # Query 1: 0.41 QPS, 0.62x concurrency, ID 0x6B78B35582099676 at byte 5708854
    # Scores: V/M = 0.01
    # Time range: 2016-07-25 08:17:47 to 19:16:35
    # Attribute    pct   total     min     max     avg     95%  stddev  median
    # ============ === ======= ======= ======= ======= ======= ======= =======
    # Count         70   16194
    # Exec time     43  24511s      1s      3s      2s      2s    94ms      1s
    # Lock time     60      1s    37us   791us    90us   125us    29us    98us
    # Rows sent      0   1.04k       0       3    0.07    0.99    0.28       0
    # Rows examine  11   2.05G   8.41k 391.42k 132.46k 380.41k 163.63k  23.58k
    # Merge passes   0       0       0       0       0       0       0       0
    # Query size    60   7.64M     495     495     495     495       0     495
    # Boolean:
    # Full join    100% yes,   0% no
    # Full scan    100% yes,   0% no
    # Tmp table    100% yes,   0% no
    # String:
    # Databases    lots
    # Hosts
    # Users        lotsprd
    # Query_time distribution
    #   1us
    #  10us
    # 100us
    #   1ms
    #  10ms
    # 100ms
    #    1s  ################################################################
    #  10s+
    # Tables
    #    SHOW TABLE STATUS FROM `lots` LIKE 't_wo_message_log'\G
    #    SHOW CREATE TABLE `lots`.`t_wo_message_log`\G
    #    SHOW TABLE STATUS FROM `lots` LIKE 't_work_order'\G
    #    SHOW CREATE TABLE `lots`.`t_work_order`\G
    # EXPLAIN /*!50100 PARTITIONS*/
    SELECT  wo.id as woId,
                     w
    .....................

    包括Overall中有的信息、查询响应时间的分布情况以及该查询”入榜”的理由。
    pt-query-digest还有很多复杂的操作,这里就不一一介绍了。比如:从PROCESSLIST中查询某个MySQL中最慢的

    查询:
    pt-query-digest –processlist h=host1

    建议:当slow log很大的时候最好还是将日志文件移到其他机器上进行分析。

     

     

    展开全文
  • 本篇文章主要介绍了详解MySql的慢查询分析及开启慢查询日志,具有一定的参考价值,感兴趣的小伙伴们可以参考一下。
  • MySQL中的日志包括:错误日志、二进制日志、通用查询日志慢查询日志等等。这里主要介绍下比较常用的两个功能:通用查询日志慢查询日志,需要的朋友可以参考下
  • 关于MySQL 通用查询日志和慢查询日志分析 (1)通用查询日志 一、通用查询日志设置 二、通用查询日志查看 (2)慢查询日志 一、慢查询日志的设置 ...四:慢日志分析工具 mysqldumpslow和mysqls...

    关于MySQL 通用查询日志和慢查询日志分析 

    (1)通用查询日志
           一、通用查询日志设置
           二、通用查询日志查看
    (2)慢查询日志
              一、慢查询日志的设置
              二:slow log的日志相关参数详解
              三:如何在线安全的清空慢查询日志
              四:慢日志分析工具 mysqldumpslow和 mysqlsla介绍
              五:慢日志监控

    MySQL中的日志包括:错误日志、二进制日志、通用查询日志、慢查询日志等等。这里主要介绍下比较常用的两个功能:通用查询日志和慢查询日志。

    1)通用查询日志:记录建立的客户端连接和执行的语句。

    2)慢查询日志:记录所有执行时间超过long_query_time秒的所有查询或者不使用索引的查询

    (1)通用查询日志

     一、通用查询日志设置

    在学习通用日志查询时,需要知道两个数据库中的常用命令:

    1)show variables like '%version%'; 

    mysql> show variables like '%version%';
    +-------------------------+------------------------------+
    | Variable_name           | Value                        |
    +-------------------------+------------------------------+
    | innodb_version          | 5.7.19                       |
    | protocol_version        | 10                           |
    | slave_type_conversions  |                              |
    | tls_version             | TLSv1,TLSv1.1                |
    | version                 | 5.7.19                       |
    | version_comment         | MySQL Community Server (GPL) |
    | version_compile_machine | x86_64                       |
    | version_compile_os      | macos10.12                   |
    +-------------------------+------------------------------+
    8 rows in set (0.01 sec)

    上述命令,显示当前数据库中与版本号相关的东西。

    2) show variables like '%general%';

    mysql> show variables like '%general%';
    +------------------+---------------------------------------------------+
    | Variable_name    | Value                                             |
    +------------------+---------------------------------------------------+
    | general_log      | OFF                                               |
    | general_log_file | /usr/local/mysql/data/yaoyingzhedeMacBook-Pro.log |
    +------------------+---------------------------------------------------+
    2 rows in set (0.00 sec)

    可以查看,当前的通用日志查询是否开启,如果general_log的值为ON则为开启,为OFF则为关闭(默认情况下是关闭的)。

    3) show variables like '%log_output%';

    mysql> show variables like '%log_output%';
    +---------------+-------+
    | Variable_name | Value |
    +---------------+-------+
    | log_output    | FILE  |
    +---------------+-------+
    1 row in set (0.00 sec)

    查看当前慢查询日志输出的格式,可以是FILE(存储在数数据库的数据文件中的hostname.log),也可以是TABLE(存储在数据库中的mysql.general_log)

    二、通用查询日志查看

    问题:如何开启MySQL通用查询日志,以及如何设置要输出的通用日志输出格式呢?

    开启通用日志查询: set global general_log=on;

    关闭通用日志查询: set globalgeneral_log=off;

    设置通用日志输出为表方式: set globallog_output=’TABLE’;

    设置通用日志输出为文件方式: set globallog_output=’FILE’;

    设置通用日志输出为表和文件方式:set global log_output=’FILE,TABLE’;

    (注意:上述命令只对当前生效,当MySQL重启失效,如果要永久生效,需要配置my.cnf)

    my.cnf文件的配置如下:

    general_log=1  #为1表示开启通用日志查询,值为0表示关闭通用日志查询

    log_output=FILE,TABLE#设置通用日志的输出格式为文件和表

    日志输出的效果图如下:

    记录到mysql.general_log表中的数据如下:

    (2)慢查询日志

    MySQL的慢查询日志是MySQL提供的一种日志记录,用来记录在MySQL中响应时间超过阈值的语句,具体指运行时间超过long_query_time值的SQL,则会被记录到慢查询日志中(日志可以写入文件或者数据库表,如果对性能要求高的话,建议写文件)。默认情况下,MySQL数据库是不开启慢查询日志的,long_query_time的默认值为10(即10秒,通常设置为1秒),即运行10秒以上的语句是慢查询语句。

    一般来说,慢查询发生在大表(比如:一个表的数据量有几百万),且查询条件的字段没有建立索引,此时,要匹配查询条件的字段会进行全表扫描,耗时查过long_query_time,则为慢查询语句。

    一、慢查询日志的设置

    0、查询slow log的状态,如示例代码所示,则slow log已经开启。

    mysql> show variables like '%slow%';
    +---------------------------+--------------------------------------------------------+
    | Variable_name             | Value                                                  |
    +---------------------------+--------------------------------------------------------+
    | log_slow_admin_statements | OFF                                                    |
    | log_slow_slave_statements | OFF                                                    |
    | slow_launch_time          | 2                                                      |
    | slow_query_log            | ON                                                     |
    | slow_query_log_file       | /usr/local/mysql/data/yaodeMacBook-Pro-slow.log |
    +---------------------------+--------------------------------------------------------+
    5 rows in set (0.00 sec)

    如果没有开启慢查询日志有以下两种方法:

    •  在配置文件[mysqld]中添加slow_query_log = ON和long_query_time = 1,然后重启MySQL即可生效。
    •   set global slow_query_log=1; 在线开启。如果MySQL发生重启,就会失效,如果要永久生效,就必选修改配置文件。

     

    1)slow_query_log_file 的值是记录的慢查询日志到文件中(注意:默认名为主机名.log,慢查询日志是否写入指定文件中,需要指定慢查询的输出日志格式为文件,相关命令为:show variables like ‘%log_output%’;去查看输出的格式)。

    2)long_query_time 指定了慢查询的阈值,即如果执行语句的时间超过该阈值则为慢查询语句,默认值为10秒。

    3)log_queries_not_using_indexes 如果值设置为ON,则会记录所有没有利用索引的查询(注意:如果只是将log_queries_not_using_indexes设置为ON,而将slow_query_log设置为OFF,此时该设置也不会生效,即该设置生效的前提是slow_query_log的值设置为ON),一般在性能调优的时候会暂时开启。
     

    2、设置慢查询开启的命令

    set global slow_query_log=1
    注: 
    slow_query_log ON为开启,OFF为关闭 
    slow_query_log_file 为慢查询日志的存放地址

    3、查询并修改慢查询定义的时间为4ms

    show variables like 'long_query_time%'
    set global long_query_time=4
    4、未使用索引的查询被记录到慢查询日志中。如果调优的话,建议开启这个选项。如果开启了这个参数,full index scan的sql也会被记录到慢查询日志中。

    show variables like 'log_queries_not_using_indexes'

    set global log_queries_not_using_indexes=1

    5、查询慢查询记录总个数

    show global status like '%Slow_queries%'; 

    或者

    show global status like '%slow%';

    mysql> show global status like '%slow%';
    +---------------------+-------+
    | Variable_name       | Value |
    +---------------------+-------+
    | Slow_launch_threads | 0     |
    | Slow_queries        | 15    |
    +---------------------+-------+
    2 rows in set (0.00 sec)

    mysql> show global status like '%Slow_queries%';
    +---------------+-------+
    | Variable_name | Value |
    +---------------+-------+
    | Slow_queries  | 15    |
    +---------------+-------+
    1 row in set (0.00 sec)

    问题:设置MySQL慢查询的输出日志格式为文件还是表,或者两者都有?

    通过命令:show variables like '%log_output%';

    mysql> show variables like '%log_output%';
    +---------------+-------+
    | Variable_name | Value |
    +---------------+-------+
    | log_output    | FILE  |
    +---------------+-------+
    1 row in set (0.00 sec)

    通过log_output的值可以查看到输出的格式,上面的值为TABLE。当然,我们也可以设置输出的格式为文本,或者同时记录文本和数据库表中,设置的命令如下:

    #慢查询日志输出到表中(即mysql.slow_log)

    set globallog_output=’TABLE’;

    #慢查询日志仅输出到文本中(即:slow_query_log_file指定的文件)

    set global log_output=’FILE’;

    #慢查询日志同时输出到文本和表中

    set global log_output=’FILE,TABLE’;  

    关于慢查询日志的表中的数据个文本中的数据格式分析:

    慢查询的日志记录myql.slow_log表中,格式如下:

    mysql> set global log_output='TABLE,file';
    Query OK, 0 rows affected (0.01 sec)

    mysql> show variables like '%log_output%';
    +---------------+------------+
    | Variable_name | Value      |
    +---------------+------------+
    | log_output    | FILE,TABLE |
    +---------------+------------+
    1 row in set (0.01 sec)

    mysql> select * from mysql.slow_log;
    Empty set (0.00 sec)

    mysql> select sleep(10) as a, 1 as b;
    +---+---+
    | a | b |
    +---+---+
    | 0 | 1 |
    +---+---+
    1 row in set (10.00 sec)

    可以看到,不管是表还是文件,都具体记录了:是那条语句导致慢查询(sql_text),该慢查询语句的查询时间(query_time),锁表时间(Lock_time),以及扫描过的行数(rows_examined)等信息。

    注意:上述所有命令,如果都是通过MySQL的shell将参数设置进去,如果重启MySQL,所有设置好的参数将失效,如果想要永久的生效,需要将配置参数写入my.cnf文件中)。

    二:slow log的日志相关参数详解

    slow_query_log :是否开启慢查询日志,1表示开启,0表示关闭。

    log-slow-queries :旧版(5.6以下版本)MySQL数据库慢查询日志存储路径。可以不设置该参数,系统则会默认给一个缺省的文件host_name-slow.log

    slow-query-log-file:新版(5.6及以上版本)MySQL数据库慢查询日志存储路径。可以不设置该参数,系统则会默认给一个缺省的文件host_name-slow.log

    long_query_time :慢查询阈值,当查询时间多于设定的阈值时,记录日志。

    log_queries_not_using_indexes:未使用索引的查询也被记录到慢查询日志中(可选项)。

    log_output:日志存储方式。log_output='FILE'表示将日志存入文件,默认值是'FILE'。log_output='TABLE'表示将日志存入数据库,这样日志信息就会被写入到mysql.slow_log表中。MySQL数据库支持同时两种日志存储方式,配置的时候以逗号隔开即可,如:log_output='FILE,TABLE'。日志记录到系统的专用日志表中,要比记录到文件耗费更多的系统资源,因此对于需要启用慢查询日志,又需要能够获得更高的系统性能,那么建议优先记录到文件。

    三:如何在线安全的清空慢查询日志

    • 停止slow log
    mysql> set global slow_query_log=0;
    Query OK, 0 rows affected (0.27 sec)
    mysql> show variables like '%slow%';
    +---------------------+------------------------------------------+
    | Variable_name       | Value                                    |
    +---------------------+------------------------------------------+
    | log_slow_queries    | OFF                                      |
    | slow_launch_time    | 2                                        |
    | slow_query_log      | OFF                                      |
    | slow_query_log_file | /mysqllog/slow_log/slow_queries_3306.log |
    +---------------------+------------------------------------------+
    4 rows in set (0.00 sec)
    #检查慢查询日志的状态
    • 为慢查询日志重新设置path路径
    mysql> set global slow_query_log_file='/mysqllog/slow_log/slow_queries_3306_new.log';
    Query OK, 0 rows affected (0.03 sec)
    • 开启慢查询日志,并设置long_query_time。
    mysql> set global slow_query_log=1;
    Query OK, 0 rows affected (0.01 sec)
    mysql>set global long_query_time=1;
    
    
    #检查状态是否成功开启
    mysql> show variables like '%slow%';
    +---------------------+----------------------------------------------+
    | Variable_name       | Value                                        |
    +---------------------+----------------------------------------------+
    | log_slow_queries    | ON                                           |
    | slow_launch_time    | 2                                            |
    | slow_query_log      | ON                                           |
    | slow_query_log_file | /mysqllog/slow_log/slow_queries_3306_new.log |
    +---------------------+----------------------------------------------+
    4 rows in set (0.00 sec)
    
    检查slow sql 在新的日志文件中
    
    mysql> select sleep(10) as a, 1 as b;
    +---+---+
    | a | b |
    +---+---+
    | 0 | 1 |
    +---+---+
    1 row in set (10.00 sec)
    
    [mysql@xxx-xxx ~]$ more /mysqllog/slow_log/slow_queries_3306_new.log
    ......
    Time                 Id Command    Argument
    # Time: 140213  6:44:24
    # User@Host: root[root] @ localhost []
    # Query_time: 10.000365  Lock_time: 0.000000 Rows_sent: 1  Rows_examined: 0
    SET timestamp=1392273864;
    select sleep(10) as a, 1 as b;
    
    备份之前的慢查询日志
    mv /mysqllog/slow_log/slow_queries_3306.log /mysqlbackup/slow_log/slow_queries_3306.log.bak.20140213
    
    四:慢日志分析工具 介绍
    
    (1)mysqldumpslow 
    命令:
        -s 按照那种方式排序
        c:访问计数
        l:锁定时间
        r:返回记录
        al:平均锁定时间
        ar:平均访问记录数
        at:平均查询时间
    -t 是top n的意思,返回多少条数据。
    -g 可以跟上正则匹配模式,大小写不敏感。
    
    得到返回记录最多的20个sql
    mysqldumpslow -s r -t 20 sqlslow.log

    Count: 414  Time=3.51s (1454s)  Lock=0.0s (0s)  Rows=2194.9(9097604), root[root]@localhost
      select * from mysql.general_log

    Count:414            语句出现了414次;

    Time=3.51s(1454)  执行最长时间为3.51s,累计总耗费时间1454s;

    Lock=0.0s(0)           等待锁最长时间为0s,累计等待锁耗费时间为0s;

    Rows=2194.9(9097604) 发送给客户端最多的行数为2194.9,累计发送给客户端的函数为90976404

    具体命令如下:

    bogon:~ a6$ sudo mysqldumpslow -s r -t 20 /usr/local/mysql/data/yaodeMacBook-Pro-slow.log;

    Password:

    Reading mysql slow query log from /usr/local/mysql/data/yaodeMacBook-Pro-slow.log
    Count: 2  Time=0.03s (0s)  Lock=0.00s (0s)  Rows=1575.0 (3150), root[root]@localhost
      select * from tk_question_ls

    Count: 2  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=5.5 (11), root[root]@localhost
      select * from tk_question_ls limit N

    Count: 1  Time=0.00s (0s)  Lock=0.02s (0s)  Rows=10.0 (10), root[root]@localhost
      select * from mysql.general_log

    Count: 1  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=5.0 (5), root[root]@localhost
      select distinct difficulty from tk_question_ls

    Count: 1  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=4.0 (4), root[root]@localhost
      select * from product

    Count: 1  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=1.0 (1), root[root]@localhost
      select * from  tk_question_ls limit N

    Count: 1  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=0.0 (0), root[root]@localhost
      select * from one_and_two_kn_accumulate_stars

    Died at /usr/local/mysql/bin/mysqldumpslow line 161, <> chunk 9.

    得到平均访问次数最多的20条sql

    mysqldumpslow -s ar -t 20 sqlslow.log

    得到平均访问次数最多,并且里面含有ttt字符的20条sql

    mysqldumpslow -s ar -t 20 -g "ttt" sqldlow.log

    注: 
    1、如果出现 -bash: mysqldumpslow: command not found 错误,请执行

    ln -s /usr/local/mysql/bin/mysqldumpslow /usr/bin

    2、如果出现如下错误,Died at /usr/bin/mysqldumpslow line 161, <> chunk 405659.说明你要分析的sql日志太大了,请拆分后再分析

    拆分的命令为:

    tail -100000 mysql-slow.log>mysql-slow.20180725.log

    (注意:mysqldumpslow脚本是用perl语言写的,具体mysqldumpslow的用法后期再讲)

    问题:实际在学习过程中,如何得知设置的慢查询是有效的?

    很简单,我们可以手动产生一条慢查询语句,比如,如果我们的慢查询log_query_time的值设置为5 s,则我们可以执行如下语句:

    select  sleep(10);

    该条语句即是慢查询语句,之后,便可以在相应的日志输出文件或表中去查看是否有该条语句。
     

    (2)慢查询分析工具mysqlsla

           慢查询分析工具还有mysqlsla,mysqlsla是hackmysql.com推出的一款MySQL的日志分析工具,功能非常强大. 数据报表,非常有利于分析慢查询的原因, 包括执行频率, 数据量, 查询消耗等。(参考https://www.cnblogs.com/skymyyang/p/7239010.html

    本文针对MySQL数据库服务器查询逐渐变慢的问题, 进行分析,并提出相应的解决办法,具体的分析解决办法如下:会经常发现开发人员查一下没用索引的语句或者没有limit n的语句,这些没语句会对数据库造成很大的影...

    五:慢查询监控

    针对MySQL数据库服务器查询逐渐变慢的问题, 进行分析,并提出相应的解决办法,具体的分析解决办法如下:

    会经常发现开发人员查一下没用索引的语句或者没有limit n的语句,这些没语句会对数据库造成很大的影响,例如一个几千万条记录的大表要全部扫描,或者是不停的做filesort,对数据库和服务器造成io影响等。这是镜像库上面的情况。

    而到了线上库,除了出现没有索引的语句,没有用limit的语句,还多了一个情况,mysql连接数过多的问题。说到这里,先来看看以前我们的监控做法 

    1. 部署zabbix等开源分布式监控系统,获取每天的数据库的io,cpu,连接数 
    2. 部署每周性能统计,包含数据增加量,iostat,vmstat,datasize的情况 
    3. Mysql slowlog收集,列出top 10

    以前以为做了这些监控已经是很完美了,现在部署了mysql节点进程监控之后,才发现很多弊端 

    第一种做法的弊端: zabbix太庞大,而且不是在mysql内部做的监控,很多数据不是非常准备,现在一般都是用来查阅历史的数据情况 
    第二种做法的弊端:因为是每周只跑一次,很多情况没法发现和报警 
    第三种做法的弊端: 当节点的slowlog非常多的时候,top10就变得没意义了,而且很多时候会给出那些是一定要跑的定期任务语句给你。。参考的价值不大 

    那么我们怎么来解决和查询这些问题呢

    对于排查问题找出性能瓶颈来说,最容易发现并解决的问题就是MYSQL的慢查询以及没有得用索引的查询。 
    OK,开始找出mysql中执行起来不“爽”的SQL语句吧。

    最后总结一下节点监控的好处 


    1. 轻量级的监控,而且是实时的,还可以根据实际的情况来定制和修改 
    2. 设置了过滤程序,可以对那些一定要跑的语句进行过滤 
    3. 及时发现那些没有用索引,或者是不合法的查询,虽然这很耗时去处理那些慢语句,但这样可以避免数据库挂掉,还是值得的 
    4. 在数据库出现连接数过多的时候,程序会自动保存当前数据库的processlist,DBA进行原因查找的时候这可是利器
    5. 使用mysqlbinlog 来分析的时候,可以得到明确的数据库状态异常的时间段 

    有些人会建义我们来做mysql配置文件设置,如下

    调节tmp_table_size 的时候发现另外一些参数 
    Qcache_queries_in_cache 在缓存中已注册的查询数目 
    Qcache_inserts 被加入到缓存中的查询数目 
    Qcache_hits 缓存采样数数目 
    Qcache_lowmem_prunes 因为缺少内存而被从缓存中删除的查询数目 
    Qcache_not_cached 没有被缓存的查询数目 (不能被缓存的,或由于 QUERY_CACHE_TYPE) 
    Qcache_free_memory 查询缓存的空闲内存总数 
    Qcache_free_blocks 查询缓存中的空闲内存块的数目 
    Qcache_total_blocks 查询缓存中的块的总数目 
    Qcache_free_memory 可以缓存一些常用的查询,如果是常用的sql会被装载到内存。那样会增加数据库访问速度

    参考:https://blog.csdn.net/sunyuhua_keyboard/article/details/81204020
               https://blog.csdn.net/timchen525/article/details/75268151  
               https://www.cnblogs.com/qmfsun/p/4844472.html

    展开全文
  • 主要介绍了MySQL慢查询日志分析的实例教程,通过设置参数从慢查询日志开始分析性能问题的原因,需要的朋友可以参考下
  • 慢查询日志分析

    万次阅读 2014-10-20 10:03:12
    慢查询日志 打开慢查询日志 慢查询日志,顾名思义就是记录执行比较慢查询日志。 查看是否开启慢查询日志: show variables like '%slow%'; 打开慢查询日志。修改MySQL的配置文件my.cn一般是...
  • mysql的slow_query_log慢查询日志分析工具说明,主要用来进行慢查询日志的linux平台分析输出结果文档进行MySQL的调优/优化数据库
  • 使用percona公司的pt-query-digest分析慢查询日志,分析、统计的结果的比较清晰
  • MySQL中的日志包括:通用查询日志、查询日志、错误日志、二进制日志等等。这里主要记录一下两种比较常用的日志:通用查询日志和查询日志。...1、查看当前通用日志查询是否开启:  show variab...
  • MySQL慢查询日志分析详解

    千次阅读 2019-06-27 12:59:56
    MySQL的慢查询日志是MySQL提供的一种日志记录,它用来记录在MySQL中响应时间超过阀值的语句,具体指运行时间超过long_query_time值的SQL,则会被记录到慢查询日志中。long_query_time的默认值为10,意思是运行10S...
  • 当应用程序后台 SQL 查询慢的时候我们一般第一时间会查看数据库慢查询记录,但是慢查询记录是原始文本,直接查询搜索分析比较费时费力,虽然业界有针对 MySQL 慢查询分析的命令行工具(比如:pt-query-digest),...
  • 2.开启慢查询日志,设置阈值,比如超过5秒钟的就是SQL, 并将它抓取出来。 3.explain+SQL分析 4.show profile 5.运维经理orDBA,进行SQL数据库服务器的参数调优。 ==========总结========== 1.慢查询的开启并...
  • 使用ELK分析Mysql慢查询日志

    千次阅读 2019-08-28 19:15:18
    4.Mysql慢查询配置 5.具体分析 6.参考资料 1.ELK介绍 1)Elasticsearch Elasticsearch 是基于 JSON 的分布式搜索和分析引擎,专为实现水平扩展、高可靠性和管理便捷性而设计。 Elasticsearch 是一个分布式的 ...
  • 主要介绍了对MySQL慢查询日志进行分析的基本教程,文中提到的Query-Digest-UI这个基于B/S的图形化查看工具非常好用,需要的朋友可以参考下
  • 一、Mysql慢查询日志开启   慢查询日志常用语句 #查看慢查询日志输出方式 show variables like '%output%' #查看慢查询文件输出位置 show variables like '%slow_query_log_file%' #查看慢查询是否开启,及...
  • mysql慢查询日志分析

    2018-08-27 12:19:39
    使用mysql慢查询日子对有效率问题sql进行监控,使用工具进行分析 是否开始慢查询日志; show variables like ‘slow_query_log';   查看变量的设置 show variables like "log%"; 将没有设置...
  • 检查是否开启慢查询日志: show variables like “%slow_query_log%”; 慢查询开启状态 show variables like “%slow_query_log_file%”; 慢查询日志文件 show variables like “%long_query_time%”; 慢查询...
  • Redis必学(六)慢查询日志分析

    千次阅读 2019-04-22 22:09:34
    慢查询日志
  • MySQL慢查询日志记录和分析

    千次阅读 2019-01-08 21:05:41
    一、引言 在日常的开发中,有时候会有用户反馈说网站的响应速度...这个时候,我们就需要慢慢分析,我们可以通过开启慢查询日志,来监控生产环境上有没有执行特别的SQL,如果有,我们可以定位到是哪一条SQL,从而...
  • mysql慢查询日志和执行计划

    千次阅读 2020-05-24 15:40:35
    什么是慢查询日志查询日志是MySQL提供的一种日志记录,它记录了在查询过程中性能不好的SQL语句...慢查询日志可以跟踪有问题的查询语句,通过分析慢查询日志我们可以知道哪些SQL语句执行的效率低下,以便对SQL语句进

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 133,535
精华内容 53,414
关键字:

如何分析慢查询日志