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、长事务因对请求响应时间、系统稳定运行存在一定影响，因此需要尽量在程序开发测试阶段识别并解决，此外还需加强投产上线的日常巡检，通过多阶段管控尽量避免问题发生，实现系统安全平稳运行。
文末了：
可以到我的个人号：atstudy-js，可以免费领取一份10G软件测试工程师面试宝典文档资料。同时我邀请你进入我们的软件测试学习交流平台，大家可以一起探讨交流软件测试，共同学习软件测试技术、面试等软件测试方方面面，了解测试行业的最新趋势，助你快速进阶Python自动化测试/测试开发，稳住当前职位同时走向高薪之路。
