mysql 利用 performance_schema 排查 qps 过高过程记录

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: mysql 利用 performance_schema 排查 qps 过高过程记录

本文章是基于 MySQL 5.7.x 版本操作的,其他版本会存在 sql 语法问题

什么是 performance schema

MySQL Performance Schema

Performance Schema System Variables

Performance Schema Startup Configuration

自官方翻译

  • Performance Schema 是用于在低级别监视 MySQL 服务器执行的功能,Performance Schema 具有以下特点

Performance Schema 提供了一种在运行时检查服务器内部执行情况的方法。

  • 它是使用 PERFORMANCE_SCHEMA 存储引擎和 performance_schema 数据库实现的。
  • PERFORMANCE_SCHEMA 主要关注性能数据。
  • 这与 INFORMATION_SCHEMA 不同,后者用于元数据检查。
  • Performance Schema监视服务器事件。
  • “事件” 是服务器执行的任何需要时间并且已被检测以便可以收集计时信息的事情。
  • 一般来说,事件可以是函数调用、等待操作系统、SQL 语句执行的一个阶段(例如解析或排序)或者整个语句或语句组。
  • 事件收集提供对有关服务器和多个存储引擎的同步调用(例如互斥锁)、文件和表 I/O、表锁等信息的访问。
  • Performance Schema 事件不同于写入服务器二进制日志(binlog)的事件(描述数据修改)和事件调度程序事件(这是一种存储程序)。
  • Performance Schema事件特定于 MySQL 服务器的给定实例。
  • performance_schema 表被视为服务器本地表,对它们的更改不会复制或写入二进制日志。
  • 提供当前事件以及事件历史记录和摘要。
  • 这使您能够确定仪表活动执行的次数以及所花费的时间。
  • 事件信息可用于显示特定线程的活动,或与特定对象(例如互斥锁或文件)关联的活动。
  • PERFORMANCE_SCHEMA 存储引擎使用服务器源代码中的 “检测点” 收集事件数据。
  • 收集的事件存储在performance_schema数据库的表中。
  • 这些表可以像其他表一样使用 SELECT 语句进行查询。
  • 可以通过 SQL 语句更新performance_schema数据库中的表来动态修改Performance Schema配置。
  • 配置更改会立即影响数据收集。
  • Performance Schema 中的表是内存表,不使用持久磁盘存储。
  • 这些内容在服务器启动时开始重新填充,并在服务器关闭时丢弃。
  • MySQL 支持的所有平台上都可以进行监控。
  • 可能存在一些限制: 计时器的类型可能因平台而异。
  • 适用于存储引擎的工具可能不适用于所有存储引擎。
  • 每个第三方发动机的仪表由发动机维护人员负责。
  • 另请参阅性能架构的限制。
  • 数据采集是通过修改服务器源码添加instrumentation来实现的。
  • 与复制或事件调度程序等其他功能不同,没有与性能架构关联的单独线程。

扩展一下 information_schema

MySQL Information Schema

INFORMATION_SCHEMA 提供对数据库元数据、有关 MySQL 服务器的信息(例如数据库或表的名称、列的数据类型或访问权限)的访问。有时用于此信息的其他术语是数据字典和系统目录

  • information_schema 是每个 MySQL 实例中的一个数据库,用于存储有关 MySQL 服务器维护的所有其他数据库的信息。
  • information_schema 数据库包含多个只读表。
  • 它们实际上是视图,而不是基表,因此没有与它们关联的文件,并且您无法在它们上设置触发器。
  • 此外,没有具有该名称的数据库目录。
  • 虽然您可以使用 USE 语句选择 information_schema 作为默认数据库,但您只能读取表的内容,而不能对其执行 INSERTUPDATEDELETE 操作。

确认是否开启 performance schema

--performance-schema 参数,官方默认值是 ON ,可以通过 MySQL 内查看

  • 查看 MySQL 版本
select version();

我这边使用的是 5.7.29 版本的

+------------+
| version()  |
+------------+
| 5.7.29-log |
+------------+
  • 查看是否开启了 performance schema
SHOW VARIABLES LIKE 'perf%';

以下是和 performance_schema 相关的参数

+----------------------------------------------------------+-------+
| Variable_name                                            | Value |
+----------------------------------------------------------+-------+
| performance_schema                                       | ON    |
| performance_schema_accounts_size                         | -1    |
| performance_schema_digests_size                          | 10000 |
| performance_schema_events_stages_history_long_size       | 10000 |
| performance_schema_events_stages_history_size            | 10    |
| performance_schema_events_statements_history_long_size   | 10000 |
| performance_schema_events_statements_history_size        | 10    |
| performance_schema_events_transactions_history_long_size | 10000 |
| performance_schema_events_transactions_history_size      | 10    |
| performance_schema_events_waits_history_long_size        | 10000 |
| performance_schema_events_waits_history_size             | 10    |
| performance_schema_hosts_size                            | -1    |
| performance_schema_max_cond_classes                      | 80    |
| performance_schema_max_cond_instances                    | -1    |
| performance_schema_max_digest_length                     | 1024  |
| performance_schema_max_file_classes                      | 80    |
| performance_schema_max_file_handles                      | 32768 |
| performance_schema_max_file_instances                    | -1    |
| performance_schema_max_index_stat                        | -1    |
| performance_schema_max_memory_classes                    | 320   |
| performance_schema_max_metadata_locks                    | -1    |
| performance_schema_max_mutex_classes                     | 210   |
| performance_schema_max_mutex_instances                   | -1    |
| performance_schema_max_prepared_statements_instances     | -1    |
| performance_schema_max_program_instances                 | -1    |
| performance_schema_max_rwlock_classes                    | 50    |
| performance_schema_max_rwlock_instances                  | -1    |
| performance_schema_max_socket_classes                    | 10    |
| performance_schema_max_socket_instances                  | -1    |
| performance_schema_max_sql_text_length                   | 1024  |
| performance_schema_max_stage_classes                     | 150   |
| performance_schema_max_statement_classes                 | 193   |
| performance_schema_max_statement_stack                   | 10    |
| performance_schema_max_table_handles                     | -1    |
| performance_schema_max_table_instances                   | -1    |
| performance_schema_max_table_lock_stat                   | -1    |
| performance_schema_max_thread_classes                    | 50    |
| performance_schema_max_thread_instances                  | -1    |
| performance_schema_session_connect_attrs_size            | 512   |
| performance_schema_setup_actors_size                     | -1    |
| performance_schema_setup_objects_size                    | -1    |
| performance_schema_users_size                            | -1    |
+----------------------------------------------------------+-------+
42 rows in set (0.00 sec)

通过 performance_schema 统计 qps 情况

查看当前 performance_schema 记录了多少 sql 语句,使用 NOT IN 来排除 MySQL 的系统库

SELECT COUNT(DIGEST_TEXT)
FROM performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME NOT IN ('performance_schema', 'information_schema', 'mysql')
ORDER BY SUM_TIMER_WAIT DESC;

可以通过 limit 的方式来看使用次数最多的 sql

SELECT 
    ROUND(SUM_TIMER_WAIT / (SELECT SUM(SUM_TIMER_WAIT) FROM performance_schema.events_statements_summary_by_digest), 2) AS latency_percentage,
    COUNT_STAR AS execution_count,
    SUM_TIMER_WAIT / COUNT_STAR AS avg_latency,
    SCHEMA_NAME,
    DIGEST_TEXT,
    LAST_SEEN
FROM performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME NOT IN ('performance_schema', 'information_schema', 'mysql')
ORDER BY SUM_TIMER_WAIT DESC LIMIT 20;

以下内容从 chartgpt 复制的

  • SUM_TIMER_WAIT:这是 Performance Schema 的一个列,表示每个 SQL 语句在执行过程中所花费的总时间(以纳秒为单位)。
  • (SELECT SUM(SUM_TIMER_WAIT) FROM performance_schema.events_statements_summary_by_digest):这是一个子查询,用于计算所有SQL语句的总执行时间,即所有 SUM_TIMER_WAIT 的总和。

ROUND(SUM_TIMER_WAIT / (SELECT SUM(SUM_TIMER_WAIT) FROM

performance_schema.events_statements_summary_by_digest), 2) AS latency_percentage:这是一个计算字段,用于计算每个 SQL 语句的执行时间在所有 SQL 语句中所占的百分比,然后使用 ROUND 函数将百分比保留两位小数。

  • COUNT_STAR AS execution_count:这是 Performance Schema 的一个列,表示每个 SQL 语句的执行次数。
  • SUM_TIMER_WAIT / COUNT_STAR AS avg_latency:这是一个计算字段,用于计算每个 SQL 语句的平均执行时间,即将 SUM_TIMER_WAIT 总和除以 COUNT_STAR(执行次数)。
  • SCHEMA_NAME:这是 Performance Schema的一个列,表示每个SQL语句所属的数据库名称。
  • DIGEST_TEXT:这是 Performance Schema 的一个列,表示每个 SQL 语句的具体内容。
  • LAST_SEEN:这是 Performance Schema 的一个列,表示每个 SQL 语句最后执行的时间。
  • FROM performance_schema.events_statements_summary_by_digest:这是指定查询的来源表,即 Performance Schema 中的 events_statements_summary_by_digest 表。该表存储了关于执行过的 SQL 语句的摘要信息。
  • WHERE SCHEMA_NAME NOT IN ('performance_schema', 'information_schema', 'mysql'):这是一个条件子句,用于排除一些系统数据库,只统计自定义数据库的SQL语句。
  • ORDER BY SUM_TIMER_WAIT DESC:这是将结果按照 SUM_TIMER_WAIT(总执行时间)从高到低进行排序,这样能够让我们看到执行时间最长的SQL语句排在前面。

综上所述,这个查询通过 Performance Schema 提供的信息,计算和展示了每个 SQL 语句的执行次数、总执行时间、平均执行时间以及其在所有 SQL 语句中的执行时间占比。这些信息对于分析数据库性能和优化查询是非常有用的。

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
SQL 关系型数据库 MySQL
Java 最常见的面试题:mysql 问题排查都有哪些手段?
Java 最常见的面试题:mysql 问题排查都有哪些手段?
|
2月前
|
SQL 关系型数据库 MySQL
MySQL如何排查和删除重复数据
该文章介绍了在MySQL中如何排查和删除重复数据的方法,包括通过组合字段生成唯一标识符以及使用子查询和聚合函数来定位并删除重复记录的具体步骤。
166 2
|
3月前
|
SQL 关系型数据库 MySQL
遇到mysql数据库死锁,你会怎么排查?
遇到mysql数据库死锁,你会怎么排查?
248 0
|
3月前
|
监控 关系型数据库 MySQL
mysql误删的performance_schema库
`performance_schema`库是MySQL性能监控的重要工具,误删除后可以通过上述方法尝试恢复。在操作过程中,重启MySQL服务器是最简单的尝试方法。如果这不起作用,可以尝试使用MySQL的初始化选项,但请注意备份数据以防数据丢失。检查MySQL配置也是一个好的步骤,以确保 `performance_schema`没有被禁用。最后,如果有备份,通过恢复备份来恢复 `performance_schema`库是最保险的方法。在操作过程中,确保遵循最佳实践和操作前备份重要数据。
158 5
|
3月前
|
SQL 关系型数据库 MySQL
破防了,谁懂啊家人们:记一次mysql问题排查
某天用户反馈线上产品报错,本文记录了这次mysql问题排查和修复的过程,希望给大家参考。
|
3月前
|
SQL 关系型数据库 MySQL
(十八)MySQL排查篇:该如何定位并解决线上突发的Bug与疑难杂症?
前面《MySQL优化篇》、《SQL优化篇》两章中,聊到了关于数据库性能优化的话题,而本文则再来聊一聊关于MySQL线上排查方面的话题。线上排查、性能优化等内容是面试过程中的“常客”,而对于线上遇到的“疑难杂症”,需要通过理性的思维去分析问题、排查问题、定位问题,最后再着手解决问题,同时,如果解决掉所遇到的问题或瓶颈后,也可以在能力范围之内尝试最优解以及适当考虑拓展性。
195 3
|
4月前
|
消息中间件 关系型数据库 MySQL
实时计算 Flink版操作报错合集之运行mysql to doris pipeline时报错,该如何排查
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
6月前
|
SQL 运维 关系型数据库
记一次 MySQL 主从同步异常的排查记录,百转千回!
这篇文章主要讲述了在 MySQL 主从同步过程中遇到的一个问题,即从库的 SQL 线程因 Relay Log 损坏导致同步停止。作者首先介绍了现象,从库的 Slave_IO_Running 正常,但 Slave_SQL_Running 停止,报错信息提示可能是 binlog 或 relay log 文件损坏。
180 6
|
6月前
|
缓存 监控 关系型数据库
2核4G 配置的MySQL 5.6如何调优为最佳qps,tps
要提高具有2核4G配置的MySQL 5.6的QPS(每秒查询率)和TPS(每秒事务数),可以通过以下方法进行调优: 1. 优化配置文件(my.cnf): 在MySQL的配置文件中,可以调整以下参数以提高性能: ``` [mysqld] innodb_buffer_pool_size = 1.5G # 设置InnoDB缓冲池大小,推荐值为服务器总内存的50%-80% max_connections = 500 # 设置最大连接数,根据实际需求进行调整 query_cache_size = 128M # 设置查询缓存大小,推荐值
533 2
|
Java 关系型数据库 MySQL
记一次mysql线上问题排查
背景是这样的,我们有个系统每天都会调起多个定时任务,首先quartz每分钟会调起一次检查时间的任务,如果发现时间到达设定的任务执行时间,java代码会向数据库里写入一条记录,然后有另外一个系统就会根据这条记录执行相应的任务,有天有同事反馈说有条定时任务没执行。。
89 0