mysql 利用 performance_schema 排查 qps 过高过程记录
本文章是基于 MySQL 5.7.x 版本操作的,其他版本会存在 sql 语法问题
什么是 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
INFORMATION_SCHEMA
提供对数据库元数据、有关 MySQL 服务器的信息(例如数据库或表的名称、列的数据类型或访问权限)的访问。有时用于此信息的其他术语是数据字典和系统目录。information_schema
是每个 MySQL 实例中的一个数据库,用于存储有关 MySQL 服务器维护的所有其他数据库的信息。information_schema
数据库包含多个只读表。- 它们实际上是视图,而不是基表,因此没有与它们关联的文件,并且您无法在它们上设置触发器。
- 此外,没有具有该名称的数据库目录。
- 虽然您可以使用
USE
语句选择information_schema
作为默认数据库,但您只能读取表的内容,而不能对其执行INSERT
、UPDATE
或DELETE
操作。
确认是否开启 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 语句中的执行时间占比。这些信息对于分析数据库性能和优化查询是非常有用的。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· Docker 太简单,K8s 太复杂?w7panel 让容器管理更轻松!