网站程序自带的采集器采集文章(一条慢查询会造成什么后果？刚开始使用慢日志)

　　网站程序自带的采集器采集文章(一条慢查询会造成什么后果？刚开始使用慢日志)

　　查询慢的后果是什么？刚开始使用 MySQL 开发的时候，初级 DBA 认为简单的查询比较慢，体验稍微受影响。然而，慢查询的破坏力远不止于此。在业务高峰期，这条SQL还没有处理完，大量新的查询请求堆积如山。CPU使用率长​​期居高不下，甚至高达100%，系统直接崩溃……查询慢等黑天鹅事件可能直接影响业务。稳定，造成巨大的经济损失。

　　慢查询，字面意思是查询慢。比如某类查询，正常情况下消耗100ms左右，异常时可能飙升到15s。为了定位查询慢的问题，我们可以按照以下步骤进行：

　　一、开启慢日志；

　　二、使用慢日志查询分析和管理工具；

　　三、在现有慢日志分析的基础上，优化系统本身（如查询语句或表结构设计）。

　　一、开启慢日志定位异常

　　默认情况下不启用慢日志。如果需要优化 SQL，可以启用该功能。登录 MySQL 后，执行如下 SQL 语句启动慢日志（这里以 MySQL 5.7.33 为例，其他版本基本通用）：

　　SETGLOBAL slow_query_log = 'ON';

　　-- 不使用索引的查询也被认为是潜在的慢查询

　　setglobal log_queries_not_using_indexes = 'ON';

　　一般情况下，MySQL慢日志位于/var/lib/mysql/-slow.log，我们可以模拟一个慢查询，然后可以看到生成的慢日志记录：

　　-- 手动触发慢查询：MySQL默认超过10s的查询为慢查询

　　选择睡眠（11);

　　看一下慢查询日志：

　　$ sudo cat /var/lib/mysql/ubt-server-slow.log

　　/usr/sbin/mysqld，版本：5.7.33-0ubuntu0.18.04.1（（Ubuntu））。开始于：

　　Tcp 端口：3306 Unix 套接字：/var/run/mysqld/mysqld.sock

　　# 时间：2021-03-12T08:52:54.227174Z

　　# 用户@主机：df-test[df-test] @ [10.100.64.118] ID：2

　　# Query_time: 11.000551 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 0

　　使用数字1；

　　设置时间戳=1615539174；

　　选择睡眠（11);

　　从这个日志中，我们可以看到以下信息（根据不同的 MySQL 版本或配置，这些信息可能会增加或减少）：

　　• 生成时间：2021-03-12T08:52:54.227174Z

　　• 来源：df-test[df-test] @ [10.100.64.118]，即用户 df-test at 10.100.64.118 这个查询是在这台机器上执行的

　　• 查询统计信息：例如经过的时间、发送/接收的行数

　　• 特定的 SQL 语句

　　从这些信息中，我们可以更清楚的知道这个慢查询的来龙去脉，更准确的定位到具体的业务代码。但是，这里有一个问题。为了保证MySQL数据库的安全，MySQL要求只有登录到特定的服务器才能看到慢查询日志的详细信息，这直接影响了发生异常时的处理效率，拖慢了异常的进度状态、分析和解决方案。

　　除了开启系统自带的慢日志，开发者还有哪些有效的方法可以快速、直接、准确的解决这个问题呢？

　　二、使用MySQL慢日志分析工具

　　常用的慢SQL优化分析工具有：mysqldumpslow、mysqlsla、mysql-explain-slow-log、mysql-log-filter、myprofi。

　　

　　这是 mysqldumpslow 和 mysql-log-filter 的示例。

　　mysqldumpslow

　　mysqldumpslow 是官方的慢查询日志分析工具。主要功能包括不同慢SQL的统计

　　• 出现次数（计数）

　　• 平均执行时间和累计总时间（时间）

　　• 等待锁定 (Lock) 所花费的时间

　　• 发送到客户端的总行数（Rows）

　　• 扫描的总行数 (Rows)

　　• 用户和SQL语句本身（格式被抽象，如limit 1, 20用limit N, N表示）

　　

　　参考：《4.6.9个mysqldumpslow-summary慢查询日志文件》

　　mysql-日志过滤器

　　在google代码上找到的一个分析工具，它为python和php提供了两个可执行脚本。基本功能比官方mysqldumpslow多了查询时间统计（平均、最大值、累积），其他类似。除统计信息外，特殊功能是对输出内容的排版和格式化，以保证整体输出的简洁性。推荐给喜欢简洁报告的朋友。

　　

　　你可以参考：

　　其他几个工具这里不再赘述。有兴趣的朋友可以直接从网上搜索。上面介绍的工具在使用中或多或少都有小问题，要么是数据丢失，要么是配置麻烦等等。下面给大家介绍一下一站式数据监控云平台（DataFlux）的解决方案。

　　DataFlux 解决方案

　　如上所述，慢日志具有很大的破坏力。为了进一步优化MySQL数据库性能，我们需要解决以下问题：

　　• 数据采集

　　• 数据分析

　　• 数据存储

　　• 数据显示和查询

　　在 DataFlux 中有一个专门用于处理各种数据的工具采集——DataKit。对于 MySQL，它为 MySQL 日志记录提供了各种 采集 功能。这里介绍Linux平台上DataKit采集器的基本使用。

　　首先，我们登录DataFlux官网进行注册，登录会员账号。然后，我们可以按照下图（控制台-管理-数据网关）找到并安装DataKit，或者参考链接2。

　　参考链接：

　　1. DataFlux 官网：

　　2.《DataKit 安装》：

　　#toc34

　　

　　安装DataKit后，在/usr/local/cloudcare/dataflux/datakit/conf.d/log/目录下，复制一份MySQL日志采集配置

　　$ sudo cp mysqlog.conf.sample mysqlog.conf

　　编辑 mysqlog.conf：

　　[[输入.tailf]]

　　# 填写各种MySQL日志的文件路径，不同版本可能不同

　　# 注意这里只支持文本文件。我们这里使用的版本是 MySQL 5.7.33

　　日志文件 = [

　　"/var/lib/mysql/*.log",

　　"/var/log/mysql/mysql.log",

　　"/var/log/mysql/error.log",

　　]

　　来源="mysqlog"

　　# 指定服务名称

　　服务="mysqlog"

　　# 专用日志解析脚本（DataKit内置）

　　管道="mysql.p"

　　[inputs.tailf.tags]

　　# 这里可以添加一些标签，比如：

　　biz = "订单系统"

　　# 省略其他默认配置...

　　至此，MySQL日志采集配置完毕，重启DataKit即可（数据在Dataflux平台上需要一段时间才能看到）

　　参考链接：《不同系统的DataKit重启方法》

　　#toc27

　　接下来，我们可以在DataFlux平台上看到对应的日志：

　　

　　从图中我们可以看出已经提取了SQL的执行时间（query_time），也就是上面慢日志中看到的时间。关注这个日志，点进去，可以看到日志详情：

　　

　　从日志明细图中，我们可以看到用红色标记的慢查询SQL语句，以及其他提取的日志信息，如查询时间、来源、服务器主机名、请求发送的数据行数等。

　　此外，在拉取的日志详情中，我们还可以看到在产生慢日志的时间点附近（红色虚线垂直线）附近该主机的当前资源使用情况（如CPU、内存、磁盘、网络）。等信息），在一定程度上可以帮助开发者更好地解决问题。

　　至此，我们解决了采集，MySQL慢日志的解析和显示问题。现在有了数据，开发者可以很容易的在网页上找到对应的慢查询日志，并根据MySQL服务器的整体资源使用情况提供更合理的解决方案。

　　以上就是我们今天针对MySQL慢日志查询问题提供的解决方案。在实际应用过程中，我们仍然需要尝试更多不同维度的解决方案，并根据自身行业和业务的特点，选择适合自己和团队的数据库分析工具，以保证系统的稳定性和商业。