MySQL Performance Schema 详解及运行时配置优化

引言

MySQL 的 Performance Schema 是一套性能监控与诊断工具,帮助开发者和数据库管理员收集、分析 MySQL 实例的运行状态,找出性能瓶颈并进行优化。通过 Performance Schema,我们能够监控不同的内部事件、线程、会话、语句执行等关键性能指标。然而,默认情况下并非所有监控项目都被启用,用户可以通过配置相关的表来灵活调整需要采集的监控数据。

本文将对 Performance Schema 相关的运行时配置表进行深入剖析,包括 performance_timerssetup_timerssetup_consumerssetup_instrumentssetup_actorssetup_objectsthreads 表的具体作用、字段含义及其配置技巧,帮助读者更好地掌握和使用 MySQL 性能调优工具。

为什么需要运行时配置?

在实际应用中,我们可能会遇到以下需求:

  • 修改默认配置:有时启动时默认配置未能启用所有需要的监控项。此时需要在运行时动态调整配置,以便捕捉到更多的性能数据。
  • 高并发场景:在高负载情况下,数据库生成了大量的事件信息。如果我们只对某些特定会话或事件感兴趣,可以在运行时调整配置,以避免数据过多导致性能问题。

通过运行时配置,我们可以更灵活地管理 Performance Schema 的数据采集和存储,从而更好地满足实际监控需求。

关键配置表及字段解释

以下是 MySQL 5.8 中与 Performance Schema 配置相关的一些重要表及其字段解释:

performance_timers 表详解

在 MySQL 中,performance_timers 表用于显示各种计时器的配置和性能参数。了解这些计时器对于精确地测量和记录性能数据至关重要。以下是 performance_timers 表中各字段的详细解释:

表结构

javascript 复制代码
mysql> SELECT * FROM performance_timers;
+-------------+-----------------+------------------+----------------+
| TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+-------------+-----------------+------------------+----------------+
| CYCLE       |      3791482587 |                1 |             22 |
| NANOSECOND  |      1000000000 |                1 |             44 |
| MICROSECOND |         1000000 |                1 |             36 |
| MILLISECOND |            1037 |                1 |             36 |
| TICK        |             105 |                1 |            596 |
+-------------+-----------------+------------------+----------------+
5 rows in set

字段解释

TIMER_NAME:计时器的名称。这些名称指代不同的时间度量方式或精度,例如 NANOSECOND 表示纳秒级别的计时器,MILLISECOND 表示毫秒级别的计时器。

TIMER_FREQUENCY:计时器的频率,以每秒计数的次数表示。例如,NANOSECOND 的频率为 1000000000,意味着每秒有 10 亿次计数。CYCLE 的频率为 3791482587,意味着每秒可以测量约 37 亿次。

TIMER_RESOLUTION:计时器的分辨率,表示计时器的最小单位。在 MySQL 中,这通常是 1,即每个计时器的最小单位是一个基本计数。所有计时器的 TIMER_RESOLUTION 为 1,表明它们的分辨率相同,能够测量最小的时间单位。

TIMER_OVERHEAD:使用该计时器时的开销,以微秒为单位。开销越低,计时器的性能越高。TICK 计时器的开销为 596 微秒,相对较高,这表明它可能在时间测量过程中引入了较大的性能开销。相比之下,NANOSECOND 计时器的开销为 44 微秒,性能较好。

使用场景

  • 选择合适的计时器 :根据性能需求选择不同的计时器。例如,如果需要高精度的性能数据,可以选择 NANOSECOND 计时器;如果性能开销更重要,可以选择开销较低的计时器,如 MICROSECOND
  • 优化性能:了解计时器的开销可以帮助我们优化性能。例如,在高负载场景下,可以选择开销更低的计时器,以减少对系统性能的影响

setup_timers 表详解

在 MySQL 中,setup_timers 表用于配置 Performance Schema 的计时器。计时器的配置决定了性能数据的测量精度。通过配置 setup_timers 表中的计时器,我们可以根据不同事件的需求选择适当的计时器类型。这种灵活的配置可以帮助我们在性能监控中取得更好的效果,既可以提高数据的精度,也可以减少性能开销。了解这些配置能够帮助优化 Performance Schema 的性能监控,使其更好地适应具体需求。

表结构

javascript 复制代码
mysql> SELECT * FROM setup_timers;
+-------------+-------------+
| NAME        | TIMER_NAME  |
+-------------+-------------+
| idle        | MICROSECOND |
| wait        | CYCLE       |
| stage       | NANOSECOND  |
| statement   | NANOSECOND  |
| transaction | NANOSECOND  |
+-------------+-------------+
5 rows in set

字段解释

NAME: 计时器类别的名称。这个字段表示 Performance Schema 用于不同类型事件的计时器配置。idle 表示空闲事件的计时器,wait 表示等待事件的计时器,stage 表示阶段事件的计时器。

TIMER_NAME: 与 performance_timers 表中的计时器名称匹配,表示用于记录该事件类别的计时器类型。MICROSECOND 表示微秒级计时器,NANOSECOND 表示纳秒级计时器,CYCLE 表示周期计时器。

配置说明

  • idle 计时器 :使用 MICROSECOND 计时器。
    • 应用:适用于记录空闲时间事件,如服务器闲置时间的精确测量。如果关心系统空闲时间的精确度,可以选择 MICROSECOND 计时器来捕捉更详细的时间数据。
  • wait 计时器 :使用 CYCLE 计时器。
    • 应用:用于记录等待事件,如等待锁或 I/O 操作的时间。如果的应用程序经常出现等待操作,选择 CYCLE 计时器可以减少计时器开销,提高性能。
  • stage 计时器 :使用 NANOSECOND 计时器。
    • 应用:用于记录 SQL 执行阶段的时间,例如从解析到执行的各个阶段。在分析复杂的 SQL 查询性能时,使用 NANOSECOND 计时器可以提供更高的精度,以便更详细地了解每个阶段的耗时。
  • statement 计时器 : 使用 NANOSECOND 计时器。
    • 应用:用于记录 SQL 语句的执行时间,包括语句的总执行时间。当需要监控单个 SQL 语句的执行性能时,使用 NANOSECOND 计时器能够提供极高的精确度。
  • transaction 计时器 :使用 NANOSECOND 计时器。
    • 应用:用于记录事务的执行时间,包括事务的开始和结束时间。对于涉及大量事务的应用,使用 NANOSECOND 计时器可以帮助精确分析事务的执行性能。

查看当前计时器配置:

javascript 复制代码
SELECT * FROM setup_timers;

更改计时器配置,例如,将 statement 事件的计时器更改为 MICROSECOND

javascript 复制代码
UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND' WHERE NAME = 'statement';

setup_consumers 表详解

在 MySQL 中,setup_consumers 表用于配置 Performance Schema 中的消费者。消费者负责从 Performance Schema 中收集并存储性能事件数据。通过配置消费者的启用状态,我们可以灵活地控制哪些类型的数据被记录和分析。通过配置 setup_consumers 表中的消费者,可以精确控制哪些性能数据被记录和分析。这种灵活的配置能够根据具体需求优化 Performance Schema 的性能监控。启用或禁用特定的消费者可以使更有效地收集和分析性能数据,从而提高数据库系统的整体性能和可靠性。

表结构

javascript 复制代码
mysql> SELECT * FROM setup_consumers;
+----------------------------------+---------+
| NAME                             | ENABLED |
+----------------------------------+---------+
| events_stages_current            | NO      |
| events_stages_history            | NO      |
| events_stages_history_long       | NO      |
| events_statements_current        | YES     |
| events_statements_history        | YES     |
| events_statements_history_long   | NO      |
| events_transactions_current      | NO      |
| events_transactions_history      | NO      |
| events_transactions_history_long | NO      |
| events_waits_current             | NO      |
| events_waits_history             | NO      |
| events_waits_history_long        | NO      |
| global_instrumentation           | YES     |
| thread_instrumentation           | YES     |
| statements_digest                | YES     |
+----------------------------------+---------+
15 rows in set

字段解释

NAME: 消费者的名称。每个消费者对应 Performance Schema 中的一个数据类型,它决定了如何收集和存储不同类型的性能事件数据。events_statements_current 记录当前正在执行的 SQL 语句的事件,global_instrumentation 用于全局性能统计。

ENABLED: 指示相应的消费者是否启用(YES 或 NO)。如果启用,消费者将开始收集相应类型的事件数据;如果禁用,则不会收集这些数据。events_statements_current 的状态为 YES,说明当前正在记录 SQL 语句的执行事件,而 events_stages_current 的状态为 NO,则表示当前不记录 SQL 执行阶段的事件。

消费者配置说明

  • events_stages_current: NO,用于记录当前 SQL 语句执行的阶段事件。由于它未启用,当前不会收集这些数据。
  • events_statements_current: YES,用于记录当前正在执行的 SQL 语句事件。这有助于实时监控 SQL 执行情况。如果需要了解当前正在执行的 SQL 语句及其性能,可以启用此消费者。
  • global_instrumentation: YES,用于记录全局性能统计信息,如锁的使用情况、文件 I/O 操作等。启用此消费者可以帮助我们获得整体系统的性能概况,从而进行更高效的性能优化。
  • statements_digest: YES,用于记录 SQL 语句的摘要信息,这有助于分析和汇总 SQL 语句的性能。如果需要对执行的 SQL 语句进行汇总和分析,可以启用此消费者,以便获取 SQL 语句的统计信息。

查看当前消费者的配置状态:

javascript 复制代码
SELECT * FROM setup_consumers;

启用 events_stages_current 消费者:

javascript 复制代码
UPDATE setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_stages_current';

禁用 events_statements_current 消费者:

javascript 复制代码
UPDATE setup_consumers SET ENABLED = 'NO' WHERE NAME = 'events_statements_current';

setup_instruments 表详解

在 MySQL 的 Performance Schema 中,setup_instruments 表用于配置各种性能事件的采集器。通过设置这些采集器,我们可以控制哪些类型的事件会被记录,它允许根据需求选择要监控的具体事件,决定是否记录时间数据,从而优化性能监控的效果和开销。通过对该表的配置,可以灵活地控制性能监控的粒度和范围,确保监控信息对系统优化和问题排查的价值最大化。

表结构

数据太多了,我们挑重点的说,我们假设执行了之后的查询:

javascript 复制代码
mysql> SELECT * FROM setup_instruments;
+--------------------------------------------------------------------------------+---------+--------+
| NAME                                                                           | ENABLED | TIMED  |
+--------------------------------------------------------------------------------+---------+--------+
| wait/synch/mutex/sql/LOCK_error_log                                            | NO      | NO    |
| wait/synch/mutex/sql/LOCK_gdl                                                  | NO      | NO    |
| wait/synch/mutex/sql/LOCK_global_system_variables                              | NO      | NO    |
| wait/synch/mutex/sql/LOCK_manager                                              | NO      | NO    |
| wait/synch/mutex/sql/LOCK_prepared_stmt_count                                  | NO      | NO    |
| wait/synch/mutex/sql/LOCK_sql_slave_skip_counter                               | NO      | NO    |
| wait/synch/mutex/sql/LOCK_slave_net_timeout                                    | NO      | NO    |
| wait/synch/mutex/sql/LOCK_slave_trans_dep_tracker                              | NO      | NO    |
| wait/synch/mutex/sql/LOCK_server_started                                       | NO      | NO    |
| wait/synch/mutex/sql/LOCK_keyring_operations                                   | NO      | NO    |
| wait/synch/mutex/sql/LOCK_socket_listener_active                               | NO      | NO    |
+--------------------------------------------------------------------------------+---------+--------+
................

字段解释

NAME: 表示要监控的特定事件或操作的名称。它通常包括事件的类别(如 wait/synch/mutex/sql)以及具体的资源(如 LOCK_error_log)。wait/synch/mutex/sql/LOCK_error_log 代表 SQL 线程在获取错误日志锁时的等待情况。

ENABLED: 指示是否启用该监控仪器(YES 或 NO)。如果为 YES,表示该监控工具正在采集数据;如果为 NO,则不采集数据。NO 表示 LOCK_error_log 不在监控范围内;YES 表示 LOCK_global_system_variables 在监控范围内。

TIMED: 指示是否记录时间数据(YES 或 NO)。如果为 YES,表示除了记录事件本身外,还记录发生该事件所花费的时间;如果为 NO,则只记录事件发生情况。NO 表示 LOCK_error_log 事件的发生时间不会被记录;YES 表示 LOCK_global_system_variables 事件的发生时间会被记录。

查看所有启用的监控仪器:

javascript 复制代码
SELECT * FROM setup_instruments WHERE ENABLED = 'YES';

查看记录时间信息的所有监控仪器:

javascript 复制代码
SELECT * FROM setup_instruments WHERE TIMED = 'YES';

启用某个监控仪器,例如启用 LOCK_error_log 并记录时间:

javascript 复制代码
UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME = 'wait/synch/mutex/sql/LOCK_error_log';

禁用某个监控仪器,例如禁用 LOCK_global_system_variables

javascript 复制代码
UPDATE setup_instruments SET ENABLED = 'NO' WHERE NAME = 'wait/synch/mutex/sql/LOCK_global_system_variables';

setup_actors 表详解

在 MySQL 的 Performance Schema 中,setup_actors 表用于配置和管理对性能数据的访问控制。通过设置这个表,可以决定哪些主机、用户和角色能够查看和收集特定的性能事件数据。通过配置 setup_actors 表中的字段,可以精确控制哪些主机、用户和角色能够访问和收集 Performance Schema 中的性能数据。正确设置这些访问控制配置可以确保性能数据的安全性和隐私性,同时也允许根据需要收集和分析性能数据。理解这些配置项能够帮助更好地管理和优化 MySQL 数据库的性能监控。

表结构

javascript 复制代码
mysql> SELECT * FROM setup_actors;
+------+------+------+---------+---------+
| HOST | USER | ROLE | ENABLED | HISTORY |
+------+------+------+---------+---------+
| %    | %    | %    | YES     | YES     |
+------+------+------+---------+---------+
1 row in set

字段解释

HOST: 指定能够访问性能数据的主机地址。可以是具体的 IP 地址、主机名或通配符。% 表示允许所有主机访问性能数据;192.168.1.% 表示只允许 192.168.1.x 网段的主机访问。

USER: 指定能够访问性能数据的用户账户。可以是具体的用户名或通配符。% 表示允许所有用户访问;admin 表示只允许用户名为 admin 的用户访问。

ROLE: 指定能够访问性能数据的用户角色。可以是具体的角色名称或通配符。% 表示允许所有角色访问;monitor 表示只允许具有 monitor 角色的用户访问。

ENABLED: 指示该配置是否启用(YES 或 NO)。如果启用,指定的主机、用户和角色将能够访问性能数据。YES 表示启用访问权限配置;NO 表示禁用访问权限配置。

HISTORY: 指示是否记录历史数据(YES 或 NO)。如果启用,历史性能数据将被记录以供后续分析。YES 表示记录历史数据;NO 表示不记录历史数据。

配置说明

  • HOST状态 :%
    • 含义:允许所有主机访问性能数据。这适用于没有特别限制主机访问的场景。如果MySQL 服务器需要允许来自任何主机的访问请求,可以将此字段设置为 %。
  • USER状态 :%
    • 含义:允许所有用户访问性能数据。这适用于没有特别限制用户访问的场景。如果所有用户都需要访问性能数据,可以将此字段设置为 %。
  • ROLE状态 :%
    • 含义:允许所有角色访问性能数据。这适用于没有特别限制角色访问的场景。如果所有用户角色都需要访问性能数据,可以将此字段设置为 %。
  • ENABLED状态 :YES
    • 含义:启用访问控制配置。这意味着上述主机、用户和角色的设置将被应用。当想启用访问控制时,可以将此字段设置为 YES。
  • HISTORY状态 :YES
    • 含义:启用历史数据记录。这允许追踪并分析过去的性能数据。当需要保留历史数据以便进行长期分析时,可以将此字段设置为 YES。

查看当前访问控制配置:

javascript 复制代码
SELECT * FROM setup_actors;

允许特定用户和主机访问性能数据:

javascript 复制代码
UPDATE setup_actors SET HOST = '192.168.1.%', USER = 'admin', ROLE = 'monitor', ENABLED = 'YES', HISTORY = 'YES';

禁用历史数据记录:

javascript 复制代码
UPDATE setup_actors SET HISTORY = 'NO' WHERE HOST = '%' AND USER = '%' AND ROLE = '%';

setup_objects 表详解

在 MySQL 的 Performance Schema 中,setup_objects 表用于配置和管理监控对象的类型和状态。该表允许指定不同类型的数据库对象(如事件、函数、过程、表、触发器)是否应该被 Performance Schema 监控,以及是否记录它们的计时信息。通过配置 setup_objects 表中的字段,可以精确控制 Performance Schema 中对数据库对象的监控策略。了解和应用这些配置项可以帮助优化性能数据的收集,并根据需要进行详细的分析和调试。

表结构

javascript 复制代码
mysql> SELECT * FROM setup_objects;
+-------------+--------------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME | ENABLED | TIMED |
+-------------+--------------------+-------------+---------+-------+
| EVENT       | mysql              | %           | NO      | NO    |
| EVENT       | performance_schema | %           | NO      | NO    |
| EVENT       | information_schema | %           | NO      | NO    |
| EVENT       | %                  | %           | YES     | YES   |
| FUNCTION    | mysql              | %           | NO      | NO    |
| FUNCTION    | performance_schema | %           | NO      | NO    |
| FUNCTION    | information_schema | %           | NO      | NO    |
| FUNCTION    | %                  | %           | YES     | YES   |
| PROCEDURE   | mysql              | %           | NO      | NO    |
| PROCEDURE   | performance_schema | %           | NO      | NO    |
| PROCEDURE   | information_schema | %           | NO      | NO    |
| PROCEDURE   | %                  | %           | YES     | YES   |
| TABLE       | mysql              | %           | NO      | NO    |
| TABLE       | performance_schema | %           | NO      | NO    |
| TABLE       | information_schema | %           | NO      | NO    |
| TABLE       | %                  | %           | YES     | YES   |
| TRIGGER     | mysql              | %           | NO      | NO    |
| TRIGGER     | performance_schema | %           | NO      | NO    |
| TRIGGER     | information_schema | %           | NO      | NO    |
| TRIGGER     | %                  | %           | YES     | YES   |
+-------------+--------------------+-------------+---------+-------+

字段解释

  1. OBJECT_TYPE: 指定要监控的数据库对象类型。常见的类型包括 EVENT(事件)、FUNCTION(函数)、PROCEDURE(过程)、TABLE(表)和 TRIGGER(触发器)。TABLE 表示监控数据库中的表;FUNCTION 表示监控数据库中的函数。
  2. OBJECT_SCHEMA: 指定要监控的对象所在的数据库(模式)。可以是具体的数据库名或通配符。mysql 表示只监控 mysql 数据库中的对象;% 表示监控所有数据库中的对象。
  3. OBJECT_NAME: 指定要监控的对象名称。可以是具体的对象名或通配符。% 表示监控所有名称的对象;users 表示监控名为 users 的对象。
  4. ENABLED: 指示该对象是否启用监控(YES 或 NO)。如果启用,Performance Schema 将监控该对象。YES 表示启用监控;NO 表示禁用监控。
  5. TIMED: 指示是否记录该对象的计时信息(YES 或 NO)。如果启用,Performance Schema 将记录该对象的执行时间。YES 表示记录计时信息;NO 表示不记录计时信息。

配置说明

  • OBJECT_TYPE状态 :EVENT, FUNCTION, PROCEDURE, TABLE, TRIGGER
    • 含义:指定监控的对象类型。可以选择要监控的特定类型。如果只关心 TABLE 类型的对象,可以设置 OBJECT_TYPE 为 TABLE。
  • OBJECT_SCHEMA状态 :%(表示所有数据库)
    • 含义:指定要监控的数据库。设置为 % 表示所有数据库。如果只对 mysql 数据库中的对象感兴趣,可以将此字段设置为 mysql。
  • OBJECT_NAME状态 :%(表示所有对象)
    • 含义:指定要监控的对象名称。设置为 % 表示所有对象。如果只对名为 orders 的表进行监控,可以将此字段设置为 orders。
  • ENABLED状态 :YES
    • 含义:启用监控配置。设置为 YES 表示 Performance Schema 将监控指定的对象。如果希望 Performance Schema 监控所有对象,可以将此字段设置为 YES。
  • TIMED状态 :YES
    • 含义:记录计时信息。设置为 YES 表示 Performance Schema 将记录对象的执行时间。如果需要详细的执行时间数据,可以将此字段设置为 YES。

查看当前对象监控配置:

javascript 复制代码
SELECT * FROM setup_objects;

启用对所有表的监控并记录计时信息:

javascript 复制代码
UPDATE setup_objects SET ENABLED = 'YES', TIMED = 'YES' WHERE OBJECT_TYPE = 'TABLE';

禁用对特定函数的监控:

javascript 复制代码
UPDATE setup_objects SET ENABLED = 'NO' WHERE OBJECT_TYPE = 'FUNCTION' AND OBJECT_NAME = 'my_function';

threads 表详解

在 MySQL 的 Performance Schema 中,threads 表用于显示系统中的线程信息。这些线程可以是执行 SQL 查询的线程,也可以是后台进程或内部线程。threads 表提供了有关 MySQL 实例中各个线程的详细信息,包括其 ID、名称、类型、状态和其他相关属性。了解这些信息有助于监控系统的运行情况,诊断性能问题,以及调试和优化

表结构

javascript 复制代码
mysql> SELECT * FROM threads;
+-----------+----------------------------------------+------------+----------------+------------------+------------------+----------------------------+---------------------+------------------+-------------------+-----------------------+------------------+------+--------------+---------+-----------------+--------------+
| THREAD_ID | NAME                                   | TYPE       | PROCESSLIST_ID | PROCESSLIST_USER | PROCESSLIST_HOST | PROCESSLIST_DB             | PROCESSLIST_COMMAND | PROCESSLIST_TIME | PROCESSLIST_STATE | PROCESSLIST_INFO      | PARENT_THREAD_ID | ROLE | INSTRUMENTED | HISTORY | CONNECTION_TYPE | THREAD_OS_ID |
+-----------+----------------------------------------+------------+----------------+------------------+------------------+----------------------------+---------------------+------------------+-------------------+-----------------------+------------------+------+--------------+---------+-----------------+--------------+
|         1 | thread/sql/main                        | BACKGROUND | NULL           | NULL             | NULL             | NULL                       | NULL                |          8319880 | NULL              | NULL                  | NULL             | NULL | YES          | YES     | NULL            |            1 |
|         2 | thread/sql/thread_timer_notifier       | BACKGROUND | NULL           | NULL             | NULL             | NULL                       | NULL                | NULL             | NULL              | NULL                  |                1 | NULL | YES          | YES     | NULL            |           46 |
|         3 | thread/innodb/io_ibuf_thread           | BACKGROUND | NULL           | NULL             | NULL             | NULL                       | NULL                | NULL             | NULL              | NULL                  | NULL             | NULL | YES          | YES     | NULL            |           47 |
|         4 | thread/innodb/io_log_thread            | BACKGROUND | NULL           | NULL             | NULL             | NULL                       | NULL                | NULL             | NULL              | NULL                  | NULL             | NULL | YES          | YES     | NULL            |           48 |
|         5 | thread/innodb/io_read_thread           | BACKGROUND | NULL           | NULL             | NULL             | NULL                       | NULL                | NULL             | NULL              | NULL                  | NULL             | NULL | YES          | YES     | NULL            |           49 |
|         6 | thread/innodb/io_read_thread           | BACKGROUND | NULL           | NULL             | NULL             | NULL                       | NULL                | NULL             | NULL              | NULL                  | NULL             | NULL | YES          | YES     | NULL            |           50 |
|         7 | thread/innodb/io_read_thread           | BACKGROUND | NULL           | NULL             | NULL             | NULL                       | NULL                | NULL             | NULL              | NULL                  | NULL             | NULL | YES          | YES     | NULL            |           51 |
|         8 | thread/innodb/io_read_thread           | BACKGROUND | NULL           | NULL             | NULL             | NULL                       | NULL                | NULL             | NULL              | NULL                  | NULL             | NULL | YES          | YES     | NULL            |           52 |
|         9 | thread/innodb/io_write_thread          | BACKGROUND | NULL           | NULL             | NULL             | NULL                       | NULL                | NULL             | NULL              | NULL                  | NULL             | NULL | YES          | YES     | NULL            |           53 |
+-----------+----------------------------------------+------------+----------------+------------------+------------------+----------------------------+---------------------+------------------+-------------------+-----------------------+------------------+------+--------------+---------+-----------------+--------------+

字段解释

THREAD_ID: 线程的唯一标识符。1 是线程 thread/sql/main 的 ID,2 是线程 thread/sql/thread_timer_notifier 的 ID。

NAME: 线程的名称。可以包括线程的类型和功能。thread/sql/main 代表主要的 SQL 线程,thread/innodb/io_read_thread 代表 InnoDB 的读线程。

TYPE: 线程的类型,通常是 BACKGROUND(后台)或 USER(用户线程)。BACKGROUND 表示后台线程,例如用于系统维护;USER 表示用户创建的线程,例如执行 SQL 查询的线程。

PROCESSLIST_ID: 线程在进程列表中的 ID。如果是后台线程,此字段通常为 NULL。NULL 表示此线程不在进程列表中,例如内部后台线程;8319880 表示特定用户线程的 ID。

PROCESSLIST_USER: 执行该线程的用户。如果线程不是用户线程,则此字段为 NULL。NULL 表示后台线程;root 表示由 root 用户执行的线程。

PROCESSLIST_HOST: 执行该线程的主机名或 IP 地址。如果线程不是用户线程,则此字段为 NULL。NULL 表示后台线程;localhost 表示来自本地主机的连接。

PROCESSLIST_DB: 线程操作的数据库名。如果线程不是用户线程,则此字段为 NULL。NULL 表示后台线程;test_db 表示正在使用的数据库。

PROCESSLIST_COMMAND: 线程正在执行的命令类型,如 Query(查询)、Sleep(休眠)等。NULL 表示后台线程没有当前执行命令;Query 表示正在执行 SQL 查询。

PROCESSLIST_TIME: 线程已执行的时间(秒)。对于后台线程,通常为 NULL。NULL 表示后台线程;120 表示线程已执行了 120 秒的操作。

PROCESSLIST_STATE: 线程当前的状态,例如 Waiting for lock(等待锁定)或 Sending data(发送数据)。NULL 表示后台线程;Sending data 表示线程正在发送数据。

PROCESSLIST_INFO: 线程执行的具体信息,如 SQL 查询语句。后台线程通常没有此信息。NULL 表示后台线程;SELECT * FROM users 表示线程正在执行的 SQL 查询。

PARENT_THREAD_ID: 父线程的 ID。如果该线程没有父线程,则此字段为 NULL。NULL 表示该线程没有父线程;1 表示线程的父线程 ID 是 1。

ROLE: 线程的角色(例如 NULL 表示没有角色信息)。NULL 表示线程没有特别的角色;对于一些特殊的线程,可能会有具体角色信息。

INSTRUMENTED: 指示线程是否被 Performance Schema 监控(YES 或 NO)。YES 表示 Performance Schema 监控该线程;NO 表示不监控。

HISTORY: 指示是否记录线程历史信息(YES 或 NO)。YES 表示记录线程历史信息;NO 表示不记录。

CONNECTION_TYPE: 连接类型,通常为 NULL 表示没有特定类型。NULL 表示没有特定连接类型;在某些情况下可能会有具体的连接类型信息。

THREAD_OS_ID: 操作系统级别的线程 ID。1 表示操作系统中的线程 ID 是 1。

查看所有正在运行的线程:

javascript 复制代码
SELECT * FROM threads;

查找所有 BACKGROUND 类型的线程:

javascript 复制代码
SELECT * FROM threads WHERE TYPE = 'BACKGROUND';

获取特定线程的信息,例如 ID 为 3 的线程:

javascript 复制代码
SELECT * FROM threads WHERE THREAD_ID = 3;

总结

MySQL 的 Performance Schema 提供了非常强大的性能监控工具,而通过合理配置 Performance Schema 的运行时表,可以灵活控制采集数据的范围和深度,避免不必要的性能开销。掌握这些配置表的使用和优化技巧,能够有效提升 MySQL 数据库的运行效率,并帮助开发者和管理员及时定位系统瓶颈。

相关推荐
聊天宝快捷回复27 分钟前
必收藏,售后客服日常回复必备的话术 (精华版)
java·前端·数据库·经验分享·微信·职场发展·快捷回复
听潮阁34 分钟前
【SpringBoot详细教程】-05-整合Druid操作数据库【持续更新】
数据库·spring boot·后端
skysukai34 分钟前
Android下MVP和MVVM模式的实践
android
2401_857636391 小时前
教师工作量绩效评估系统
数据库
Passion不晚1 小时前
【面试题】mysql中怎么保持主从数据库一致
数据库·mysql·面试
Python私教1 小时前
解决macOS安装redis以后不支持远程链接的问题
数据库·redis·macos
Python私教1 小时前
macOS安装MySQL以后如何配置环境变量
数据库·mysql·macos
wrx繁星点点2 小时前
Java 事务隔离级别及相关概念
java·开发语言·数据库·mysql
百成Java2 小时前
基于springboot的旅游网站
java·spring boot·后端·mysql·spring·智能家居·旅游
穷人小水滴3 小时前
Android (rust) vulkan (JNI) 画一个三角形: VulkanSurfaceView 初始化
android·开发语言·rust·gpu·jni·vulkan·surfaceview