在mysql数据库存在高并发或者数量非常大的情况下,我们往往需要对它的性能进行监控,以防出现数据库运行缓慢或者无响应甚至崩溃等问题,那么mysql性能监控指标有哪些?
一、MySQL性能监控关键性指标
mysql性能监控涉及的指标可能多大上百个,我们主要关注监控四个方面的核心统计指标,如下:
- 查询吞吐量
- 查询性能
- 连接情况
- 缓冲池使用情况
针对这四大核心指标,我们分别解释下:
1、查询吞吐量
所谓吞吐量(TPS)是指系统在单位时间内处理请求的数量。MySQL有一个名为 Questions
的内部计数器 (根据 MySQL 用语, 这是一个服务器状态变量),客户端每发送一个查询语句, 其值就会加1,由 Questions 指标带来的以客户端为中心的视角常常比相关的 Queries 计数器更容易解释。
通过如下指令,可以查询诸如 Questions 或 Com_select 服务器状态变量的值:
SHOW GLOBAL STATUS LIKE "Questions";
我们也可以监控读、写指令的分解情况,从而更好地理解数据库的工作负载、找到可能的瓶颈。通常,读取查询会由 Com_select
指标抓取,而写入指令则主要由下面这3种指标组成,可自行分解查询监控:
Writes = Com_insert + Com_update + Com_delete
2、查询性能
MySQL 用户监控查询延迟的方式有很多,既可以通过 MySQL 内置的指标,也可以通过查询性能模式。从 MySQL 5.6.6 版本开始默认启用,MySQL 的performance_schema 数据库中的表格存储着服务器事件与查询执行的低水平统计数据。
性能模式的 events_statements_summary_by_digest 表格中保存着许多关键指标,抓取了与每条标准化语句有关的延迟、错误和查询量信息。这里就不做展开,一般我们会按模式计算以微秒为单位的平均运行时间,具体使用如下SQL即可:
SELECT schema_name , SUM(count_star) count , ROUND( (SUM(sum_timer_wait) / SUM(count_star)) / 1000000) AS avg_microsec FROM performance_schema.events_statements_summary_by_digest WHERE schema_name IS NOT NULL GROUP BY schema_name;
SELECT schema_name , SUM(sum_errors) err_count FROM performance_schema.events_statements_summary_by_digest WHERE schema_name IS NOT NULL GROUP BY schema_name;
2)sys模式
对于特别查询或调查,使用 MySQL 的 sys 模式通常更为简单。sys 模式以人们更易读的格式提供了一个有条理的指标集合,使得对应的查询更加简单。比如:
a)我们可以通过如下sql查询最慢的语句(运行时间在 95 名开外):
SELECT * FROM sys.statements_with_runtimes_in_95th_percentile;
SELECT * FROM sys.statements_with_errors_or_warnings;
3)慢查询
什么是慢查询?慢查询指在MySQL数据库中慢查询是在日志中记录执行速度慢的SQL语句,这个功能需要被开启才能被使用。主要是在mysql核心配置文件的[mysqld]中新增类似如下配置:
log slow queries = /var/lib/mysql/mysql-slow.log long_query_time = 10
除了性能模式与 sys 模式中丰富的性能数据,MySQL 还提供了一个 Slow_queries
计数器,每当查询的执行时间超过 long_query_time
参数指定的值之后,该计数器就会增加。默认情况下,该临界值设置为10秒。我们可以通过如下SQL查询超时时间,也可以设置超时时间:
#查询 SHOW VARIABLES LIKE 'long_query_time'; #设置(系统运行时临时调整) SET GLOBAL long_query_time = 3;
3、连接情况
我们可以通过如下语句查询运行的最大连接数,MySQL 默认的连接数限制为 151,超过就会拒绝客户端连接。
SHOW VARIABLES LIKE 'max_connections';
一般我们服务器可以连接成败上千个,可以通过如下的方式修改设置:
#方式1:核心配置文件新增 max_connections = 200 #方式2:系统运行时临时修改 SET GLOBAL max_connections = 500;
但我们更关心的是监控连接使用率,主要还需参考指标如下:
- Threads_connected:记录连接的线程数,每个连接对应一个线程
- Threads_running:帮助你分隔在任意时间正在积极处理查询的线程与那些虽然可用但是闲置的连接。
- Connection_errors_max_connections:连接数超过max时,该指标会开始增加,同时追踪所有失败连接尝试的 Aborted_connects 指标也会开始增加
- Connection_errors_internal:该指标只会在错误源自服务器本身时增加。内部错误可能反映了内存不足状况,或者服务器无法开启新的线程。
4、缓冲池使用情况
MySQL 默认的存储引擎 InnoDB 使用了一片称为缓冲池的内存区域,用于缓存数据表与索引的数据。缓冲池指标属于资源指标,而非工作指标,前者更多地用于调查(而非检测)性能问题。如果数据库性能开始下滑,而磁盘 I/O 在不断攀升,扩大缓冲池往往能带来性能回升。
默认设置下,缓冲池的大小通常相对较小,仅为 128M,建议可将其扩大至专用数据库服务器物理内存的80%左右。缓冲池大小调整操作是分块进行的,缓冲池的大小必须为块的大小乘以实例的数目再乘以某个倍数。缓冲池大小和块数可以通过如下sql查询:
SHOW GLOBAL VARIABLES LIKE "innodb_buffer_pool_chunk_size"; SHOW GLOBAL VARIABLES LIKE "innodb_buffer_pool_instances";
MySQL 提供了许多关于缓冲池及其利用率的指标。其中一些有用的指标能够追踪缓冲池的总大小,缓冲池的使用量,以及其处理读取操作的效率。
指标 Innodb_buffer_pool_read_requests
及 Innodb_buffer_pool_reads
对于理解缓冲池利用率都非常关键。Innodb_buffer_pool_read_requests
追踪合理读取请求的数量,而 Innodb_buffer_pool_reads
追踪缓冲池无法满足,因而只能从磁盘读取的请求数量。我们知道,从内存读取的速度比从磁盘读取通常要快好几个数量级,因此,如果 Innodb_buffer_pool_reads
的值开始增加,意味着数据库性能大有问题。
缓冲池利用率是在考虑扩大缓冲池之前应该检查的重要指标。利用率指标无法直接读取,但是可以通过下面的方式简单地计算得到:
(Innodb_buffer_pool_pages_total - Innodb_buffer_pool_pages_free) / Innodb_buffer_pool_pages_total
总结
以上就是mysql性能监控指标4个核心指标,作为java开发人员,主要了解一下即可,更专业的还是得更专业的DBA来。