1.背景说明

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

　　2.performance_schema特性介绍

　　(1)performance_schema 是运行在较低级别的用于监控MySQL Server运行过程中的资源消耗、资源等待等情况的一个功能特性，可以高效便捷实现对数据库事务和慢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、长事务因对请求响应时间、系统稳定运行存在一定影响，因此需要尽量在程序开发测试阶段识别并解决，此外还需加强投产上线的日常巡检，通过多阶段管控尽量避免问题发生，实现系统安全平稳运行。

作者：常斌    

来源：http://www.51testing.com/html/72/n-7802672.html