MySQL的慢日志线上问题及优化方案

MySQL 慢日志(slow log)是 MySQL DBA 及其他开发、运维人员需经常关注的一类信息。使用慢日志可找出执行时间较长或未走索引等 SQL 语句,为进行系统调优提供依据。

本文将结合一个线上案例,分析如何正确设置 MySQL 慢日志参数和使用慢日志功能,并介绍下网易云 RDS 对 MySQL 慢日志功能的增强。

MySQL 参数组功能

网易云 RDS 实例提供了参数组管理功能,可通过参数管理界面查看绝大部分常用的 MySQL 系统参数,用户可了解当前运行值和建议值:

用户还可通过参数管理页面对所列的参数进行修改,点击 “修改参数” 按钮进行在线设置,点击 “保存修改” 即可一键完成 MySQL 主从节点的参数修改:

查看参数管理界面不难发现,与慢查询相关的参数比较多,那么,这些参数都是如何起作用的呢,相互关系又是如何,满足什么条件的 SQL 语句才会记录到慢日志中?只有了解这些才能更好地利用慢日志进行系统调优和问题定位。

下面,我们以这个线上案例为依托,介绍下该如何正确配置慢日志参数:

有用户报告,他们使用的多个 RDS 5.7 版本实例慢日志异常,明明执行了一分多钟的 SQL 语句,却没有记录到慢日志中。还提供了用于复现的 SQL 语句。

慢日志参数正确配置姿势

首先,我们需要确认该实例是否开启了慢日志功能,默认情况下,MySQL 慢日志功能是关闭的。慢日志开关参数为 slow_query_log,可在 mysqld 启动命令行或配置文件中显式指定,若指定 slow_query_log=1 或不指定值,则表示开启慢日志,赋值为 0 表示关闭。用户可以在运行时动态开启和关闭。

网易云 RDS 实例默认开启慢日志功能,我们确认了该用户未关闭实例的慢日志开关。

接下来,需确认慢日志记录位置,MySQL 使用 log_output 参数指定以文件(FILE)还是以表 (TABLE) 的方式来保存慢日志。需要强调的是,仅指定 log_output 而将 slow_query_log 置为 0 并不会记录慢日志,也就是说 slow_query_log 才是慢日志的开关。若使用文件形式记录慢日志,则可通过 slow_query_log_file 指定文件名,如果用户没有显式指定 slow_query_log_file,则 MySQL 将其初始化为 host_name-slow.log,host_name 即为运行 mysqld 的主机名,慢日志文件默认位于 MySQL 数据目录。

网易云 RDS 实例不允许用户修改日志文件路径,但可以配置 log_output 参数,通过查询,确认该实例以文件方式记录慢日志,查看日志文件确认没有用户所述的 SQL 语句。

由于用户提供了复现语句,我们执行了其 SQL 语句,确实 1 分多钟才返回,通过 explain 命令发现其未走索引,扫描了较多的记录数,再次查看慢日志仍没有记录该 SQL 语句。

MySQL 会记录满足执行时间超过 long_query_time 秒,扫描记录数超过 min_examined_row_limit 行的 SQL 语句。

long_query_time 参数最小值和默认值分别为 1 和 10s,该参数可以精确到微秒(ms)。如果选择将慢日志记录到文件中,那么所记录的时间精确到微秒,如果记录到慢日志表(mysql.slow_log)中,那么仅精确到秒,微秒部分被忽略。

网易云 RDS 实例允许用户设置这两个参数值,那么是不是用户调整了上述两个阈值,导致无法满足记录条件呢,进一步查询发现也不是问题原因所在。

我们注意到 MySQL 还有个名为 log_queries_not_using_indexes 的参数用于控制是否记录未走索引的 SQL 查询,代码如下:

重点关注箭头所指内容,如果查询未走索引或者索引无效,且相关参数开启,那么 warn_no_index 设置为 true,若同时满足扫描记录数超过阈值,也会像慢查询一样被记录,那么是不是该参数未开呢?结果仍是否定的。

问题原因之所在

由于数据库实例中可能有较多不走索引的 SQL 语句,若开启 log_queries_not_using_indexes,则存在日志文件或表容量增长过快的风险,此时可通过设置 log_throttle_queries_not_using_indexes 来限制每分钟写入慢日志中的不走索引的 SQL 语句个数,该参数默认为 0,表示不开启,也就是说不对写入 SQL 语句条数进行控制。

启用后,系统会在第一条不走索引的查询执行后开启一个 60s 的窗口,在该窗口内,仅记录最多 log_throttle_queries_not_using_indexes 条 SQL 语句。超出部分将被抑制,在时间窗结束时,会打印该窗口内被抑制的慢查询条数以及这些慢查询一共花费的时间。下一个统计时间窗并不是马上创建,而是在下一条不走索引的查询执行后开启。

对应到该线上问题,log_throttle_queries_not_using_indexes 被设置为 10,在日志文件中看到周期性打印了如下内容:

确实符合上面描述的现象,用户的慢日志应该是被抑制了,汇总到了 359 里面去。我们尝试将 log_throttle_queries_not_using_indexes 设置为 0,再执行对应的 SQL 语句,果然在日志文件中记录了相应的 SQL 语句。

这个线上问题似乎已经定位到了,就是系统产生的不走索引的慢日志太多,而设置的 log_throttle_queries_not_using_indexes 太小,导致无法正常记录用户未走索引的慢日志。但还有一个疑惑点没有解决,那就是 log_throttle_queries_not_using_indexes 为 0 时,每分钟并没有打印超过10条慢日志,更没有 throttle 提示的 359 条这么多,那么设置为 10 的时候用户提供的那条 SQL 语句应该被记录到慢日志中才对啊,为何没有记录,原因何在?其实,仔细看下 MySQL 记录不走索引的日志的代码逻辑可以找到答案:

上图是记录慢日志的主逻辑,是否记录日志由函数 log_slow_applicable 控制,该函数先前已分析了一部分,我们进一步看该函数的其他相关内容,见下图红框:

Suppress_logging 是个决定性的变量,只有它为 false,该 SQL 语句才可能被记录。其结果就跟 log_throttle_queries_not_using_indexes 相关,我们进一步看下 log_throttle_qni.log 相关实现,如下图:

Eligible 即为 warn_no_index,inc_log_count() 函数在 1 分钟内不走索引的语句总数超过 log_throttle_queries_not_using_indexes 时返回值为 true,只有 warn_no_index 和 inc_log_count() 返回值都为 true,suppress_current 才为 true,而 suppress_current 即为 suppress_logging。

通过对上述 2 个截图内容进行分析,可以解答之前的疑惑点:

log_throttle_queries_not_using_indexes 统计的是所有不走索引的语句,其中有些语句因为不满足扫描记录数的约束而不会记录到慢日志中,这就是为什么该值为 10 的时候,慢日志文件中并没有 10 条记录。因为这 10 条中有 8 条 SQL 语句由于扫描记录数太少并没有被记录。

这也解惑了上图中 359 这个数字,它是这个时间窗内不走索引的 SQL 语句总数。所以,log_throttle_queries_not_using_indexes 是个很关键的参数,设置不当会无法正常记录不走索引的慢查询,导致慢日志功能部分失效。所以,用户首先需尽可能避免出现大量不走索引的 SQL 语句,可以通过 RDS 健康检查功能进行优化,再次,若出现慢日志中存在上述提示,应该调大 log_throttle_queries_not_using_indexes 的值,以便以进一步分析问题。

InnoSQL 慢日志功能增强

还有部分 RDS 实例用户问我们,为什么我的 SQL 语句执行时间没有超过所设置的 long_query_time,而且走了索引,但还是被记录到慢日志中,是不是出 Bug 了?其实这不是 Bug,而是因为网易云 RDS 使用的 InnoSQL(网易维护的 MySQL 开源分支)版本对慢日志做了优化,除了考察 SQL 语句的执行时间外,还关注该查询所需的磁盘页面(Disk Page)数,因为所需的页面数目过多,也可能会对系统负载造成较大影响。为了能够量化统计,我们收集了 SQL 查询所需读取的总页面数和这些页面中实际进行 IO 的次数,分别记录为 logical_reads和physical_reads,前者包括命中 InnoDB Buffer Pool 和未命中需要进行 IO 的页面请求。

通过引入 slow_query_type 和 long_query_io 两个参数为用户提供该功能。前者可设置为 0/1/2/3。“1” 表示启用基于执行时间来记录慢日志,“2” 表示基于搜索总页面数来记录慢日志,“3” 是 “1” 和 “2” 的合集。所以在 InnoSQL 中,SQL 查询只需满足执行时间够长或所需总页面数够多即可记录到慢日志中。代码实现片段如下:

页面数阈值通过 long_query_io 参数来衡量,用户可动态设置,如果总页面数 m_logical_reads 超过了该值,即使执行时间未超标,也会被记录。相应的,RDS 实例慢日志表结构和慢日志文件输出内容也增加了新的字段。

上图即为 InnoSQL 版的 slow_log 表结构,其中,logical_reads 和 physical_reads 为 InnoSQL 增加字段。同样的,慢日志文件的输出内容也增加了两个字段,如下所示:

除了以上详细描述的内容外,MySQL 慢日志模块还有如下几个特性值得关注:

○ 进行慢日志统计及慢日志中所记录的时间并不包括该 SQL 语句开始执行前获取锁所需等待的时间;

○ MySQL 在 SQL 语句执行完且所持有的锁均已释放后才将其写入慢日志中,所以慢日志中的 SQL 语句记录顺序并不能准确反映这些 SQL 语句的实际执行顺序;

○ 每条慢日志都包含一个时间戳,若写入文件中,log_timestamps 参数用于将慢日志时间戳转化为指定时区的时间。但该参数对于 mysql.slow_log 表中的慢日志不起作用;

○ 可通过设置 log_slow_slave_statements 来开启 MySQL 从库的慢日志功能;

○ ALTER TABLE, ANALYZE TABLE, CHECK TABLE, CREATE INDEX, DROP INDEX, OPTIMIZE TABLE, and REPAIR TABLE 等表管理操作也能够被记录到慢日志中,可通过 log_slow_admin_statements 选项开启。

(0)

相关推荐

  • mysql 5.5 开启慢日志slow log的方法(log_slow_queries)

    1.MySQL 5.5命令行里面 复制代码 代码如下: set global log_slow_queries = on;                               # 开启慢日志 set [session|global]  long_query_time =0.2               # 设置时间.精确的毫秒 set global  log_queries_not_using_indexes = on;   # 设置无索引的查询 2.查看存放日志的形式 mysql>

  • 根据mysql慢日志监控SQL语句执行效率

    根据mysql慢日志监控SQL语句执行效率 启用MySQL的log-slow-queries(慢查询记录). 在Linux环境下先要找到my.cnf文件(一般在/etc/mysql/),然后可能会发现该文件修改后无法保存,原因是你没有相应的权限,可以从属性中看到该文件的所有者是root,这时要先以root的身份打开它: sudo nautilus /etc/mysql 接着再打开my.cnf文件然后找到[mysqld]标签在下面加上: log-slow-queries=/path/slow.lo

  • MySQL中按时间获取慢日志信息的方法

    今天处理一个case: 数据库异常,连接数突增. 想着分析一下慢日志,可是一看慢日志都好几G了,而且是短日志格式,找到那个时间点相对比较难.于是写了一个脚本从慢日志按时间提取点日志.脚本: https://github.com/wubx/mysql-binlog-statistic/blob/master/bin/cutlogbytime 使用方法: 复制代码 代码如下: cutlogbytime #用于从慢日志用截取一个时间段的日志方便分析 ./cutlogbytime /path/slowl

  • MySQL的慢日志线上问题及优化方案

    MySQL 慢日志(slow log)是 MySQL DBA 及其他开发.运维人员需经常关注的一类信息.使用慢日志可找出执行时间较长或未走索引等 SQL 语句,为进行系统调优提供依据. 本文将结合一个线上案例,分析如何正确设置 MySQL 慢日志参数和使用慢日志功能,并介绍下网易云 RDS 对 MySQL 慢日志功能的增强. MySQL 参数组功能 网易云 RDS 实例提供了参数组管理功能,可通过参数管理界面查看绝大部分常用的 MySQL 系统参数,用户可了解当前运行值和建议值: 用户还可通过参

  • MySQL 线上日志库迁移实例

    说说最近的一个案例吧,线上阿里云RDS上的一个游戏日志库最近出现了一点问题,随着游戏人数的增加,在线日志库的数据量越来越大,最新的日志库都已经到50G大小了,在线变更的时间非常长. 之前之所以没有发现,是因为之前一直没有进行过日志库的变更,但是随着业务的深入,需要增加一些游戏属性,要对之前的日志库进行变更,这样一来,长时间的维护窗口让业务方和DBA都望而却步,日志优化迫在眉睫. 首先看日志库的情况: 1.日志库中数据量大于5000w的大表有5张: 2.这5张表开量前每个月的数据量大概在2000w

  • 线上MYSQL同步报错故障处理方法总结(必看篇)

    前言 在发生故障切换后,经常遇到的问题就是同步报错,数据库很小的时候,dump完再导入很简单就处理好了,但线上的数据库都150G-200G,如果用单纯的这种方法,成本太高,故经过一段时间的摸索,总结了几种处理方法. 生产环境架构图 目前现网的架构,保存着两份数据,通过异步复制做的高可用集群,两台机器提供对外服务.在发生故障时,切换到slave上,并将其变成master,坏掉的机器反向同步新的master,在处理故障时,遇到最多的就是主从报错.下面是我收录下来的报错信息. 常见错误 最常见的3种情

  • MySQL线上死锁分析实战

    前言 MySQL 的锁机制相信大家在学习 MySQL 的时候都有简单的了解过,那既然有锁就必定绕不开死锁这个问题.其实 MySQL 在大部分场景下是不会存在死锁问题的(比如并发量不高,SQL 写得不至于太拉胯的情况),但是在高并发的业务场景下,一不注意就会产生死锁,而这个死锁分析起来也比较麻烦. 前段时间在公司实习的时候就遇到了一个比较奇怪的死锁,之前一直没来得及好好整理,最近有空复现了一下,算是积累一点经验. 业务场景 简单说一下业务背景,公司做的是电商直播,我负责的是主播端相关的业务.而这个

  • Python线上环境使用日志的及配置文件

    目录 瞎比比 与 print 相比 logging 有什么优势? 基础用法 保存到文件 多模块使用 logging 使用配置文件配置 logging 瞎比比 这篇文章其实早在一个月之前就写好了.奈何,加班猛如虎,真的怕了.直至今天才幸运地有了个双休,赶紧排版一下文章发布了.以下为正文. 在初学 Python 的时候,我们使用 print("hello world") 输出了我们的第一行代码.在之后的日子里,便一直使用 print 进行调试(当然,还有 IDE 的 debug 模式).但

  • MySQL 线上数据库清理数据的方法

    01 场景分析 今天下午,开发的同事提来一个需求,需要在线上要删除一些数据记录,简单看了看数据的分布,大概是要删除数据表中的两千七百多万条记录,数据表的总记录是两千八百多万,也就是说,要删除的记录占了总记录的绝大部分比重,两千七百多万的数据记录,要是删除的话,使用的时间是相当长的,对线上的业务肯定会造成影响.这里将实际的应用案例简单重构为以下方法: mysql> select date,count(*) from test.tbl_a group by date; +----------+---

  • 线上MySQL的自增id用尽怎么办

    目录 表定义自增值id InnoDB系统自增row_id Xid Innodb trx_id InnoDB数据可见性的核心思想 thread_id 总结 MySQL的自增id都定义了初始值,然后不断加步长.虽然自然数没有上限,但定义了表示这个数的字节长度,计算机存储就有上限.比如,无符号整型(unsigned int)是4个字节,上限就是2^32 - 1.那自增id用完,会怎么样? 表定义自增值id 表定义的自增值达到上限后的逻辑是:再申请下一个id时,得到的值保持不变. mysql> crea

  • spring boot线上日志级别动态调整的配置步骤

    目录 前言 正文 springboot版本:1.5.7 配置 文末结语 前言 日志模块是每个项目中必须的,用来记录程序运行中的相关信息.一般在开发环境下使用DEBUG级别的日志输出,为了方便查看问题,而在线上一般都使用INFO级别的日志,主要记录业务操作的日志.那么问题来了,当线上环境出现问题希望输出DEBUG日志信息辅助排查的时候怎么办呢?修改配置文件,重新打包然后上传重启线上环境,之前确实是这么做的.下面会介绍使用动态调整线上日志级别来解决这个问题. 正文 spring boot版本:1.5

  • MySQL数据库线上修改表结构的方法

    目录 一.MDL元数据锁 1.什么是MDL锁 2.MDL锁的问题 二.如何线上修改MySQL表结构 一.MDL元数据锁 在修改表结构之前,先来看下可能存在的问题. 1.什么是MDL锁 MySQL有一个把锁,叫做MDL元数据锁,当对表修改的时候,会自动给表加上这把锁,也就是不需要自己显式使用. 当对表做增删改查的时候,加的是MDL读锁 当对表结构做变更修改的时候,加的是MDL写锁 读与读之间不互斥,读与写,写与写之间互斥,因此 当有一个线程对表执行增删盖茶的时候,会阻塞掉别的线程对表结构修改的请求

  • ELK搭建线上日志收集系统

    目录 ELK环境安装 docker-compose脚本 安装要点 分场景收集日志 Logback配置详解 完全配置 配置要点解析 使用默认的日志配置 springProperty filter appender logger 控制框架输出日志 Logstash配置详解 完全配置 配置要点 SpringBoot配置 Kibana进阶使用 ELK环境安装 ELK是指Elasticsearch.Kibana.Logstash这三种服务搭建的日志收集系统,具体搭建方式可以参考<SpringBoot应用整

随机推荐