1.背景说明

对于使用关系型数据库的系统而言，在系统投产上线后，及时发现程序运行中的慢SQL语句，能有效降低系统运行风险；对于分布式应用系统来说，在系统日常运行中，为避免因数据库长事务导致主备切换风险，实现对数据库长事务的监控，也是必不可少的。本文以MySQL数据库为例，概述通过数据库自带功能特性performance_schema实现对慢SQL和长事务的监控方法。

2.performance_schema特性介绍

(1)performance_schema是运行在较低级别的用于监控MySQLServer运行过程中的资源消耗、资源等待等情况的一个功能特性，可以高效便捷实现对数据库事务和慢SQL的监控。

(2)performance_schema的数据只保存在本地server的内存中，该库的数据发生变化时不会被写入binlog中，也不会通过复制机制被复制到其他server中，因此如果服务器重启，则历史数据丢失。

3.performance_schema监控简介

(1)慢SQL监控主要包含performance_schema的语句事件表，一般通过*_history、*_history_long表查询相关历史记录即可，*_current作为实时监控表仅供必要时参考。

(2)事务监控主要包含performance_schema的事务事件表，一般通过*_history、*_history_long表查询相关历史记录，*_current实时监控表仅供必要时参考参考。

(3)因performance_schema中无法通过特定标识实现对慢SQL/事务的监控，因此一般需要利用请求执行时段作为筛选条件，实现对慢SQL/事务的监控和命中。

(4)performance_schema计时器说明：

1)事件的时间信息包含TIMER_START、TIMER_END、TIMER_WAIT共3个字段，q其单位均为皮秒（10-12秒）。TIMER_START和TIMER_END值分别表示事件开始时间、结束时间，TIMER_WAIT是事件持续时间，是衡量是否为长事务的主要指标。

2)时间信息都是相对计时器基线（“时间零点”）以来的皮秒，计时器基线指自服务器启动期以来的时间。

3)如果事件尚未完成，TIMER_END则为当前计时器值并且TIMER_WAIT是到目前为止经过的时间(TIMER_END-TIMER_START)。

4.使用performance_schema监控步骤详解

以事务监控为例，详细说明performance_schema用法。

(1)performance_schema支持查验

若PERFORMANCE_SCHEMA对应的Support列值为YES，则说明支持。

--检查当前数据库版本是否支持performance_schema

show engines;

(2)查看performance_schema启用是否生效

--查看performance_schema启用是否生效

show variables like'performance_schema';

(3)直接访问performance_schema相关表

1)获取实例启动时间

获取实例已运行时间，用当前时间-实例已运行时间=实例启动时间。

--获取实例已运行时间，单位为秒

show global status like'uptime';

2)事件执行时段获取

事件执行时段相关字段为TIMER_START、TIMER_END，计算方法为：

TIMER_START=请求执行开始时间-实例启动时间；

TIMER_END=请求执行结束时间-实例启动时间。

3)长事务筛选

长事务查询根据计算得出的事件开始时间TIMER_START、事件结束时间TIMER_END，系统设定长事务响应时间阈值TIMER_WAIT共同实现。例如：

--查询某执行时段，事务响应时间超过0.01秒的数据库事务：

select*from performance_schema.events_statements_history

where TIMER_START>=3600000000000000 and TIMER_END<=216000000000000000

and TIMER_WAIT>=10000000000;

(4)示例

请求执行时段为XXX，长事务响应时间阈值为0.01s，长事务查询过程如下：

1)获取实例启动时间

当前时间为2024/6/3 21:25:28，实例已运行时间为185270秒，则：

实例启动时间=2024/6/3 21:25:28-185270

=2024/6/1 17:57:38

2)事件执行时段获取

根据上一步骤，获取实例启动时间为2024/6/1 17:57:38，已知请求执行时段为2024/6/3 20:36:15-2024/6/3 20:36:17，则可得事件开始时间TIMER_START、事件结束时间TIMER_END分别为：

TIMER_START=2024/6/3 20:36:15-2024/6/1 17:57:38

=182317秒

=182317000000000000皮秒

TIMER_END=2024/6/3 20:36:17-2024/6/1 17:57:38

=182319秒

=182319000000000000皮秒

3)长事务筛选

已知事件开始时间TIMER_START、事件结束时间TIMER_END分别为182317000000000000皮秒、182319000000000000皮秒，系统长事务响应时间阈值为0.01s即10000000000皮秒，则据此组成筛选条件访问事务相关表：

--查询执行时段为2024/6/3 20:36:15-2024/6/3 20:36:17，响应时间超过0.01秒的数据库事务：

select*from performance_schema.events_statements_history

where TIMER_START>=182317000000000000 and TIMER_END<=182319000000000000

and TIMER_WAIT>=10000000000;

可根据查询结果中的SQL_TEXT字段定位对应SQL语句，附图如下：

5.总结

数据库慢SQL、长事务因对请求响应时间、系统稳定运行存在一定影响，因此需要尽量在程序开发测试阶段识别并解决，此外还需加强投产上线的日常巡检，通过多阶段管控尽量避免问题发生，实现系统安全平稳运行。

文末了，我邀请你进入我们的软件测试学习交流群，大家可以一起探讨交流软件测试，共同学习软件测试技术、面试等软件测试方方面面，了解测试行业的最新趋势，助你快速进阶Python自动化测试/测试开发，稳住当前职位同时走向高薪之路。

最后：

1）关注+私信回复：“测试”，可以免费领取一份10G软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！

2）关注+私信回复："入群" 就可以邀请你进入软件测试群学习交流~~