MySQL 性能监控4大指标——第一部分(mysql索引)

网友投稿 773 2022-09-23

本站部分文章、图片属于网络上可搜索到的公开信息,均用于学习和交流用途,不能代表睿象云的观点、立场或意见。我们接受网民的监督,如发现任何违法内容或侵犯了您的权益,请第一时间联系小编邮箱jiasou666@gmail.com 处理。

MySQL 性能监控4大指标——第一部分(mysql索引)

MySQL 是什么?

关键 MySQL 统计指标

查询吞吐量查询执行性能连接情况缓冲池使用情况

MySQL 用户可以接触到数百个数据库指标,因此,在本文中,笔者将专注于能帮助我们实时了解数据库健康与性能的关键指标。

不同版本与技术的兼容性

本系列文章讨论的一些监控策略只适用于 MySQL 5.6与5.7版本。这些版本间的差异将在后文中提及。

本文列出的大多数指标与监控策略同样适用于与 MySQL 兼容的技术,诸如 MariaDB 与 Percona 服务器,不过带有一些明显的差别。例如,MySQL Workbench(工作台)中的一些特性(在本系列第二篇中有详细介绍)就与当下的一些 MariaDB 版本不兼容。

查询吞吐量

名称描述指标类型可用性
Questions已执行语句(由客户端发出)计数Work:吞吐量服务器状态变量
Com_selectSELECT 语句Work:吞吐量服务器状态变量
Writes插入,更新或删除Work:吞吐量根据服务器状态变量计算得到

在监控任何系统时,你最关心的应该是确保系统能够高效地完成工作。数据库的工作是运行查询,因此在本例中,你的首要任务是确保 MySQL 能够如期执行查询。

通过以下指令,查询诸如 Questions 或 Com_select 服务器状态变量的值:

SHOW GLOBAL STATUS LIKE "Questions";+---------------+--------+| Variable_name | Value  |+---------------+--------+| Questions     | 254408 |+---------------+--------+

你也可以监控读、写指令的分解情况,从而更好地理解数据库的工作负载、找到可能的瓶颈。通常,读取查询会由 Com_select 指标抓取,而写入查询则可能增加三个状态变量中某一个的值,这取决于具体的指令:

Writes = Com_insert + Com_update + Com_delete

应该设置告警的指标:Questions

当前的查询速率通常会有起伏,因此,如果基于固定的临界值,查询速率常常不是一个可操作的指标。但是,对于查询数量的突变设置告警非常重要——尤其是查询量的骤降,可能暗示着某个严重的问题。

查询性能

名称描述指标类型可用性
查询运行时间每种模式下的平均运行时间Work:性能性能模式查询
查询错误出现错误的 SQL 语句数量Work:错误性能模式查询
Slow_queries超过可配置的long_query_time 限制的查询数量Work:性能服务器状态变量

性能模式语句摘要

性能模式的 events_statements_summary_by_digest 表格中保存着许多关键指标,抓取了与每条标准化语句有关的延迟、错误和查询量信息。从该表截取的一行样例显示,某条语句被执行了两次,平均执行用时为 325 毫秒(所有计时器的测量值都以微微秒为单位):

*************************** 1. row ***************************                SCHEMA_NAME: employees                                         DIGEST: 0c6318da9de53353a3a1bacea70b4fce                               DIGEST_TEXT: SELECT * FROM `employees` WHERE `emp_no` > ?                 COUNT_STAR: 2                         SUM_TIMER_WAIT: 650358383000                         MIN_TIMER_WAIT: 292045159000                         AVG_TIMER_WAIT: 325179191000                         MAX_TIMER_WAIT: 358313224000                           SUM_LOCK_TIME: 520000000                                 SUM_ERRORS: 0                             SUM_WARNINGS: 0                  SUM_ROWS_AFFECTED: 0                           SUM_ROWS_SENT: 520048                    SUM_ROWS_EXAMINED: 520048          ...                              SUM_NO_INDEX_USED: 0          SUM_NO_GOOD_INDEX_USED: 0                                  FIRST_SEEN: 2016-03-24 14:25:32                                    LAST_SEEN: 2016-03-24 14:25:55

select * from employees where emp_no >200;SELECT * FROM employees WHERE emp_no > 80000;

想要按模式抽取出以微秒为单位的平均运行时间,你可以这样查询性能模式:

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;+--------------------+-------+--------------+| schema_name        | count | avg_microsec |+--------------------+-------+--------------+| employees          |   223 |       171940 || performance_schema |    37 |        20761 || sys                |     4 |          748 |+--------------------+-------+--------------+

相似地,按模式计算出现错误的语句总数,可以这么做:

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;+--------------------+-----------+| schema_name        | err_count |+--------------------+-----------+| employees          |         8 || performance_schema |         1 || sys                |         3 |+--------------------+-----------+

sys 模式

SELECT * FROM sys.statements_with_runtimes_in_95th_percentile;

或者查看哪些标准化语句出现了错误:

SELECT * FROM sys.statements_with_errors_or_warnings;

慢查询

除了性能模式与 sys 模式中丰富的性能数据,MySQL 还提供了一个 Slow_queries 计数器,每当查询的执行时间超过 long_query_time 参数指定的值之后,该计数器就会增加。默认情况下,该临界值设置为10秒。

SHOW VARIABLES LIKE 'long_query_time';+-----------------+-----------+| Variable_name   | Value     |+-----------------+-----------+| long_query_time | 10.000000 |+-----------------+-----------+

long_query_time 参数的值可通过一条指令进行调整。例如,将慢查询临界值设置为5秒:

SET GLOBAL long_query_time = 5;

(请注意,你可能要关闭会话,再重新连接至数据库,这些更改才能在会话层生效。)

调查查询性能问题

如果你的查询运行得比预期要慢,很可能是某条最近修改的查询在捣鬼。如果没有发现特别缓慢的查询,接下来就该评估系统级指标,寻找核心资源(CPU,磁盘 I/O,内存以及网络)的限制。CPU 饱和与 I/O 瓶颈是常见的问题根源。你可能还想检查 Innodb_row_lock_waits 指标,该指标记录着 InnoDB 存储引擎不得不停下来获得某行的锁定的次数。从 MySQL 5.5 版本起,InnoDB 就是默认的存储引擎,MySQL 对 InnoDB 表使用行级锁定。

应该设置告警的指标:

查询运行时间:管理关键数据库的延迟至关重要。如果生产环境中数据库的平均查询运行时间开始下降,应该寻找数据库实例的资源限制,行锁或表锁间可能的争夺,以及客户端查询模式的变化情况。查询错误:查询错误的猛增可能暗示着客户端应用或数据库本身的问题。你可以使用 sys 模式快速查找可能导致问题的查询。例如,列举出返回错误数最多的10条标准化语句:

SELECT * FROM sys.statements_with_errors_or_warnings ORDER BY errors DESC LIMIT 10;

敬请期待本文第二部分,主要介绍 MySQL 连接与缓冲池。

上一篇:MySQL 性能监控4大指标——第二部分(mysql数据库基础知识)
下一篇:如何借助 HealthKit 打造一款健身应用?(如何借助集体的力量成就自己)
相关文章

 发表评论

暂时没有评论,来抢沙发吧~