MySQL sys Schema 简单介绍-1

其他 2018-12-31 14:41:23 阅读次数: 0

参考文档：

  1. MySQL- 5.7 sys schema笔记
  2. MySQL 5.7新特性：SYS库详解
  3. MySQL Performance Schema&sys Schema介绍
  4. 内存分配统计视图 | 全方位认识 sys 系统库
  5. MySQL sys Schema
  6. 初相识 | 全方位认识sys系统库
  7. MySQL 5.7 Reference Manual / MySQL sys Schema

虽然MySQL5.7中有sys Schema这样子的特性，提供了一系列视图查看MySQL数据库当前的运行状态和性能信息，但是一直以来都使用过和认真的阅读过相关的文档。正好这次部门有一个比较的重要的线下计算系统每天半夜计算的时候总是内存报使用率95%以上，同时伴有数据库被操作系统kill掉的情况发生。在调查原因的过程中，使用了sys schema 的相关功能，特此记录下。

1. sys schema 介绍

从mysql5.5开始mysql提供了performance_schema性能引擎，可以通过查询这个库获取当前MySQL的运行状态。但是这个库比较复杂，而且查询和操作起来也不是方便，因此从5.7开始提供了sys Schema 库方便DBA进行操作。sys schema的基础数据都来自于performance和information_shcema两个库，本身不存储及集采数据。

2. sys schema 功能

在这里来介绍下sys schema都可以提供哪些数据。在sys schema 中提供了大量的对象，这些对象包括视图，表，触发器，函数，存储过程等。通过以下的语句查询overview视图，就可以知道sys库中有多少的对象。 可以看出这个库中就一个表，其他的绝大部分是视图。

mysql> use sys
Database changed
mysql> select * from schema_object_overview where db='sys';
+-----+---------------+-------+
| db  | object_type   | count |
+-----+---------------+-------+
| sys | PROCEDURE     |    26 |
| sys | VIEW          |   100 |
| sys | BASE TABLE    |     1 |
| sys | INDEX (BTREE) |     1 |
| sys | TRIGGER       |     2 |
| sys | FUNCTION      |    22 |
+-----+---------------+-------+
6 rows in set (16.84 sec)

2.2 sys中的视图

在sys库中占绝大多数的对象是视图。如果通过show tables命令查看库中的对象，会发现这些视图有2种不同的形式。 例如显示当前mysql服务器实际使用了多少内存的视图有如下的形式：

memory_global_total
x$memory_global_total

那么这两种形式的视图有什么不同呢？

  1. 以字母开头的视图是经过转换后，便于人类阅读的形式。
  2. 以 "x" 开头的视图，是没有经过格式化的，方便程序进行处理。
    例如通过以下2个视图的对比，就可以看出区别。
mysql> select * from memory_global_total;
+-----------------+
| total_allocated |
+-----------------+
| 183.85 MiB      |
+-----------------+
1 row in set (0.09 sec)

mysql> select * from x$memory_global_total;
+-----------------+
| total_allocated |
+-----------------+
|       192784960 |
+-----------------+
1 row in set (0.00 sec)

接下来对sys schema中的其他视图做下简单的介绍，库中视图汇总如下：

视图 描述
host开头的视图 以主机层面为视角，统计相关的信息
user开头的视图 以用户的视角统计相关的信息
innodb开头的视图 在innodb引擎层面，统计innodb buffer信息和事务等待innodb锁信息
io开头的视图 以i/o层面，统计io相关的信息
memory开头的视图 以内存层面为视角，统计分析内存使用情况相关信息
schema开头的视图 以schema层面为视角，统计schema相关信息
session开头的视图 以会话层面为视角，统计用户连接相关的信息
statement开头的视图 在sql语句层面，统计和分析相关语句的信息
statements开头的视图 以语句层面为视角，统计分析出错的语句，进行全表扫描， 运行时间超长，排序等语句的信息
wait开头的视图 以wait层面为视角，统计相关信息
metrics开头的视图 数据库内部的统计值信息
processlist开头的视图 线程相关的信息(包含内部线程及用户连接）

接下来将介绍几个使用比较多的视图：

  1. host 开头的视图
  2. user开头的视图
  3. innodb开头的视图
  4. io开头的视图
  5. memory开头的视图

2.2.1 host 开头的视图

2.2.1.1 host_summary表

host_summary表按host分组统计了语句的执行时间，次数，相关文件的IO，连接数和内存分配等信息。这个视图拥有列如下：

列名 作用
host 客户端连接的主机名或IP
statements 总共执行的语句数
statement_latency 语句执行所花费的总时间
statement_avg_latency 执行的语句数据平均耗时
table_scans 一共发送了多少次全表扫描
file_ios 文件io事件总次数
file_io_latency 文件io事件总执行时间
current_connections 当前连接数
total_connections 总共的连接数
unique_users （去重）用户总数
current_memory 当前账户分配的内存数
total_memory_allocated 该host总计分配的内存数 
mysql> select * from host_summary limit 1 \G
*************************** 1. row ***************************
                  host: XXXXX
            statements: 2048
     statement_latency: 4.81 s
 statement_avg_latency: 2.35 ms
           table_scans: 917
              file_ios: 7882
       file_io_latency: 2.51 s
   current_connections: 0
     total_connections: 6
          unique_users: 1
        current_memory: 0 bytes
total_memory_allocated: 0 bytes

2.2.1.2 host_summary_by_file_io表

从host角度分组统了I/O的总体情况。这个视图拥有列如下：

列名 作用
host 客户端连接的主机名或IP
ios 总I/O请求数据
io_latency I/O请求消耗的总时间 
mysql> select * from host_summary_by_file_io limit 1 \G
*************************** 1. row ***************************
      host: localhost
       ios: 136686048
io_latency: 3.07 d
1 row in set (0.02 sec)

2.2.1.3 host_summary_by_file_io_type表

从host角度，统计了每个I/O事件的信息。 这个视图拥有列如下：

列名 作用
host 客户端连接的主机名或IP
event_name I/O事件名称
total 总共发生了多少次I/O事件
total_latency I/O请求消耗的总时间
max_latency 最大IO执行时间 
mysql> select * from host_summary_by_file_io_type limit  1 \G
*************************** 1. row ***************************
         host: XXXXXX
   event_name: wait/io/file/sql/FRM
        total: 2868
total_latency: 1.62 s
  max_latency: 71.06 ms
1 row in set (0.08 sec)

2.2.1.4 host_summary_by_stages表

从host角度，统计了每个I/O事件各个阶段的信息。这个视图拥有如下的列：

列名 作用
host 客户端连接的主机名或IP
event_name 文件io事件各个阶段名称（注意和上一个视图的区别，这里记录的是事件各个阶段的名称）
total 总共发生了多少次I/O事件
total_latency I/O请求消耗的总时间
max_latency 最大I/O执行时间 
mysql> select * from host_summary_by_stages limit 1 \G
*************************** 1. row ***************************
         host: background
   event_name: stage/innodb/buffer pool load
        total: 1
total_latency: 4.17 ms
  avg_latency: 4.17 ms
1 row in set (0.00 sec)
2.2.1.5 host_summary_by_statement_latency表

按照host角度，统计了host执行语句的总体情况。包括执行的sql语句数，执行时间，锁等待时间，返回的数据量等信息。 这个视图拥有如下的列：

列名 作用
host 客户端连接的主机名或IP
total 总共执行了多少语句
total_latency 所有语句执行的时间汇总
max_latency 语句最长执行时间
lock_lateccy 锁等待的总计时间
rows_sent 当前host总计通过语句返回了多少的数据
rows_affected 当前host总计更改了多少的数据
full_scans 当前host全表扫描的次数 
mysql> select * from host_summary_by_statement_latency limit 1 \G
*************************** 1. row ***************************
         host: localhost
        total: 123861
total_latency: 1.24 d
  max_latency: 1.68 h
 lock_latency: 6.03 s
    rows_sent: 41473119
rows_examined: 13417905908
rows_affected: 12801220
   full_scans: 5059
2.2.1.6 host_summary_by_statement_type表

按照host和语句的执行类型，分组统计了包括执行的sql语句数，执行时间，锁等待时间，返回的数据量等信息。这个视图只返回执行时间不为0的统计信息。
这个视图拥有如下的列：

列名 作用
host 客户端连接的主机名或IP
statement 最后一次执行的语句名
total 总共执行了多少语句
total_latency 所有语句执行的时间汇总
max_latency 语句最长执行时间
lock_lateccy 锁等待的总计时间
rows_sent 当前host总计通过语句返回了多少的数据
rows_affected 当前host总计更改了多少的数据
full_scans 当前host全表扫描的次数

在这里提到的语句执行类型是什么呢？来看下表里的数据就知道了。从下面的结果可以看出执行语句的类型，就是执行的是select，update等等语句。

mysql> select distinct statement   from host_summary_by_statement_type  ;
+-----------------------+
| statement             |
+-----------------------+
| select                |
| create_table          |
| alter_table           |
| update                |
| insert                |
| insert_select         |
| delete                |
| drop_table            |
| show_databases        |
| show_tables           |
| show_fields           |
| show_variables        |
| show_status           |
| show_engine_status    |
| show_slave_status     |
| show_grants           |
| show_create_table     |
| show_table_status     |
| show_triggers         |
| load                  |
| set_option            |
| lock_tables           |
| unlock_tables         |
| change_db             |
| replace               |
| replace_select        |
| flush                 |
| rollback              |
| commit                |
| begin                 |
| delete_multi          |
| update_multi          |
| show_warnings         |
| show_create_func      |
| show_procedure_status |
| show_function_status  |
| show_create_trigger   |
| error                 |
| stmt                  |
| set                   |
| jump                  |
| jump_if_not           |
| freturn               |
| Quit                  |
| Init DB               |
| set_case_expr         |
| Ping                  |
+-----------------------+
47 rows in set (0.01 sec)
mysql> select *  from host_summary_by_statement_type  limit 1 \G
*************************** 1. row ***************************
         host: XXXX
    statement: select
        total: 191798
total_latency: 57.59 s
  max_latency: 208.20 ms
 lock_latency: 22.66 s
    rows_sent: 412
rows_examined: 12479336
rows_affected: 0
   full_scans: 106
1 row in set (0.01 sec)

2.2.2 innodb 开头的视图

innodb开头的视图，主要是显示innodb buffer相关的统计信息。虽然这个库提供了不少innodb buffer的相关信息，但是查询这些表的相关信息会一定程度是上影响数据库的性能。mysql官方文档上有如下的提示:

Warning
Querying views that access the INNODB_BUFFER_PAGE table can affect performance. Do not query these views on a production system unless you are aware of the performance impact and have determined it to be acceptable. To avoid impacting performance on a production system, reproduce the issue you want to investigate and query buffer pool statistics on a test instance.

2.2.2.1 innodb_buffer_stats_by_schema表

按数据分组统计了innodb buffer的相关信息。这个视图拥有如下的列：

列名 作用
object_schema 数据库名称
allocated 分配给当前这个库的总字节数(包括了数据和其他相关的内容的总大小)
data 分配给当前这个库的字节数(数据总大小)
pages 分配给当前这个库的页面数
pages_hashed 分配给当前这个库的hash页数
pages_old 分配给当前数据库的旧页数
rows_cached 当前有多少行缓存在buffer中 
mysql> select * from innodb_buffer_stats_by_schema limit 1 \G
*************************** 1. row ***************************
object_schema: XXXXX
    allocated: 38.59 GiB
         data: 35.58 GiB
        pages: 2528767
 pages_hashed: 163354
    pages_old: 782043
  rows_cached: 73175818
1 row in set (2 min 25.12 sec)
2.2.2.2 innodb_buffer_stats_by_table表

从表的角度提供innodb buffer 的统计信息。这个视图拥有如下的列：

列名 作用
object_schema 数据库名称
allocated 分配给当前这个库的总字节数(包括了数据和其他相关的内容的总大小)
data 分配给当前这个库的字节数(数据总大小)
pages 分配给当前这个库的页面数
pages_hashed 分配给当前这个库的hash页数
pages_old 分配给当前数据库的旧页数
rows_cached 当前有多少行缓存在buffer中 
mysql> select * from innodb_buffer_stats_by_table limit 1 \G
*************************** 1. row ***************************
object_schema: XXX
  object_name: XXX
    allocated: 23.08 GiB
         data: 15.88 GiB
        pages: 1512638
 pages_hashed: 745355
    pages_old: 213638
  rows_cached: 207340166
1 row in set (3 min 52.70 sec)
2.2.2.3 innodb_lock_waits表

这个视图汇总了innodb事物正在等待的锁的情况。这个视图拥有如下的列：

列名 作用
wait_started 锁等待的开始时间
wait_age 锁已经等待了多长时间
wait_age_secs 以秒为单位显示锁已经等待的时间（5.7.9中添加此列）。
locked_table 被锁的表
locked_index 被锁住的索引
locked_type 锁类型
waiting_trx_id 正在等待的事务ID
waiting_trx_started 正在等待的事务开始的时间
waiting_trx_age 正在等待的事务等待了多长时间
waiting_trx_rows_locked 有多少行记录被当前的事物锁住
waiting_trx_rows_modified 正在等待的事务，修改的行数量
waiting_pid 正在等待的事务所属的线程ID，既show processlist看到的ID
waiting_query 正在等待的事物，当前正在执行的语句
waiting_lock_id 锁的ID
waiting_lock_mode 锁的模式
blocking_trx_id 阻塞的事务的id
blocking_pid 阻塞的事务所属的线程ID，既show processlist看到的ID
blocking_query 阻塞的事务当前正在执行的操作
blocking_lock_id 阻塞事务的锁的id
blocking_lock_mode 阻塞的模式
blocking_trx_started 阻塞的事务的开始时间
blocking_trx_age 阻塞的事务的已经执行了多少时间
blocking_trx_rows_locked 阻塞的事务锁住了多少行
blocking_trx_rows_modified 阻塞的事务修改了多少行
sql_kill_blocking_query kill语句杀死正在运行的阻塞事务
sql_kill_blocking_connection kill语句杀死会话中正在运行的阻塞事务

我们来看看当有个阻塞的事物的时候，这个表中数据的情况：
1.首先建立一个表 ,同时有数据如下：

mysql> show create table test_lock  \G
*************************** 1. row ***************************
       Table: test_lock
Create Table: CREATE TABLE `test_lock` (
  `id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

mysql> select * from test_lock;
+-----+
| id  |
+-----+
|   3 |
|  10 |
| 100 |
+-----+
3 rows in set (0.00 sec)

2.事务1

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> update test_lock set id =2  where id =10;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

3.事物2

mysql> begin ;
mysql> select * from test_lock where id = 10 for update ;

4.show processlist

*************************** 8. row ***************************
     Id: 1690543
   User: xxxx
   Host: localhost
     db: test
Command: Query
   Time: 2
  State: statistics
   Info: select * from test_lock where id = 10 for update

5.查看表可以有如下的数据：

mysql> select * from innodb_lock_waits \G
*************************** 1. row ***************************
                wait_started: 2018-12-31 01:26:54
                    wait_age: 00:00:20
               wait_age_secs: 20
                locked_table: `test`.`test_lock`
                locked_index: PRIMARY
                 locked_type: RECORD
              waiting_trx_id: 294360748
         waiting_trx_started: 2018-12-30 23:18:16
             waiting_trx_age: 02:08:58
     waiting_trx_rows_locked: 5
   waiting_trx_rows_modified: 0
                 waiting_pid: 1690543
               waiting_query: select * from test_lock where id = 10 for update
             waiting_lock_id: 294360748:30180851:3:2
           waiting_lock_mode: X
             blocking_trx_id: 294360747
                blocking_pid: 1690288
              blocking_query: NULL
            blocking_lock_id: 294360747:30180851:3:2
          blocking_lock_mode: X
        blocking_trx_started: 2018-12-30 23:17:59
            blocking_trx_age: 02:09:15
    blocking_trx_rows_locked: 1
  blocking_trx_rows_modified: 2
     sql_kill_blocking_query: KILL QUERY 1690288
sql_kill_blocking_connection: KILL 1690288
1 row in set, 3 warnings (0.04 sec)

可以看出 waiting开头的部分就是事务2，正在等待锁的事务。而blocking开头的就是正在阻塞其他进程的事务。

2.2.3 io 开头的视图

以I/O层面为视角，统计I/O相关的信息。

2.2.3.1 io_by_thread_by_latency 表

这个视图从线程的角度，统计了I/O的延迟情况（I/O时间消耗）这个视图拥有以下的列：

列名 作用
user 对于当前线程来说，这个值是线程被分配的账户，对于后台线程来讲，就是线程的名称
total I/O事件的总数
total_latency I/O总体延迟时间（总体花费的时间）
min_latency 单个I/O事件最小延迟
avg_latency 平均I/O的延迟
max_latency 单个I/O事件最大延迟
thread_id 线程ID
processlist_id 对于当前线程就是此时的ID，对于后台就是null 
mysql> select * from io_by_thread_by_latency limit 1 \G
*************************** 1. row ***************************
          user: XXXXX
         total: 3982138
 total_latency: 46.85 m
   min_latency: 384.48 ns
   avg_latency: 8.60 ms
   max_latency: 50.59 s
     thread_id: 30
processlist_id: NULL
1 row in set (0.04 sec)
2.2.3.2 io_global_by_file_by_bytes 表

这个视图从每个文件的角度，统计了I/O的情况（主要显示文件写入和读取的byte数量）。这个视图拥有以下的列：

列名 作用
file 文件名
count_read 总共发生了多少读取的I/O事件
total_read 总计读取了多少byte从文件中
avg_read 每次I/O平均从文件中读取了多少byte
count_write 总计发生了多少次写入的I/O事件
total_written 总计写入了多少byte到文件中
avg_write 每次I/O平均写入多少byte到文件中
total 总共有多少byte被读取和写入到文件中
write_pct 写入的byte占总请求的比例 
mysql> select * from io_global_by_file_by_bytes limit 1 \G
*************************** 1. row ***************************
         file: XXXXX
   count_read: 124097831
   total_read: 1.85 TiB
     avg_read: 16.00 KiB
  count_write: 154762
total_written: 2.36 GiB
    avg_write: 16.00 KiB
        total: 1.85 TiB
    write_pct: 0.12
1 row in set (0.03 sec)
2.2.3.3 io_global_by_file_by_latency表(misc是啥)

这个视图从每个文件的角度，统计了I/O的情况（主要显示I/O的时间延迟）。这个视图拥有以下的列：

列名 作用
file 文件名
total I/O事件的总数
total_latency I/O时间总体花费的时间
count_read 总共发生了多少读取的I/O事件
read_latency 读请求I/O的总延迟
count_write 总计发生了多少次写入的I/O事件
write_latency 写请求I/O的总延迟
count_misc 其他的I/O请求的数量
misc_latency 其他I/O请求总计延迟 
mysql> select * from  io_global_by_file_by_latency limit 1 \G
*************************** 1. row ***************************
         file: XXXXX.ibd
        total: 58795939
total_latency: 7.52 h
   count_read: 56231839
 read_latency: 7.47 h
  count_write: 2372895
write_latency: 1.51 m
   count_misc: 191205
 misc_latency: 1.18 m
1 row in set (0.02 sec)
2.2.3.4 io_global_by_wait_by_bytes表

这个视图从I/O事件的角度（显示的时候会有wait/io/file/ 这样子的前缀），统计了I/O的情况（主要显示I/O的时间延迟，和写入和读取的byte数）。这个视图拥有如下的列：

列名 作用
event_name I/O事件名称，显示的时候会有wait/io/file/ 这样子的前缀
total I/O事件发生的总数
total_latency I/O事件的定时发生的总等待时间
min_latency I/O事件定时发生的最短单个等待时间
avg_latency 每次定时发生I / O事件的平均等待时间
max_latency I/O事件定时发生的最大单个等待时间
count_read I/O事件的读取请求数
total_read 总计读取的byte数据
avg_read 平均每个I/O事件读取的byte数
count_write I/O事件的写入请求数
total_written 总计写入的byte数
avg_written 平均每个I/O事件
total_requested 总计byte 被读取和写入 
mysql> select * from io_global_by_wait_by_bytes limit 1  \G
*************************** 1. row ***************************
     event_name: innodb/innodb_data_file
          total: 762718061
  total_latency: 2.47 d
    min_latency: 0 ps
    avg_latency: 279.74 us
    max_latency: 16.23 s
     count_read: 743120377
     total_read: 11.07 TiB
       avg_read: 16.00 KiB
    count_write: 17834643
  total_written: 484.40 GiB
    avg_written: 28.48 KiB
total_requested: 11.55 TiB
1 row in set (0.03 sec)

2.2.4 memory开头的视图

以内存层面为视角，统计分析内存使用情况相关信息。

2.2.4.1 memory_by_host_by_current_bytes表

从host层面，统计当前内存使用的情况，这个视图拥有以下的几个列：

列名 作用
host 主机名
current_count_used 尚未被host释放的当前已分配内存块数
current_allocated 尚未被host释放的当前已分配字节数
current_avg_alloc host每个内存块的当前分配字节数
current_max_alloc host的最大单个当前内存分配（以字节为单位）
total_allocated 主机的总内存分配（以字节为单位） 
mysql>  select * from memory_by_host_by_current_bytes order by current_allocated desc \G
*************************** 1. row ***************************
              host: background
current_count_used: 0
 current_allocated: 0 bytes
 current_avg_alloc: 0 bytes
 current_max_alloc: 0 bytes
   total_allocated: 0 bytes

其他几个相关的表，结构和作用都差不多，不过从其他的层面进行统计，这里就不多做介绍了：

  1. memory_by_thread_by_current_bytes
  2. memory_by_user_by_current_bytes
  3. memory_global_by_current_bytes
  4. memory_global_total

2.2.5 user开头的表

user开头的表，主要从user的角度统计相关的信息。

2.2.5.1 user_summary表

这个表在用户的维度统计了语句的执行情况，I/O和连接数等情况。这个表拥有如下的列：

列名 作用
user 用户
statements 总共执行了多少语句
statement_latency 执行语句花费的总时间
statement_avg_latency 语句平均执行时间
table_scans 全表扫描的次数
file_ios 总共发生了多少次文件I/O
file_io_latency 对应用户执行的语句产生的文件I/O事件的总延迟时间(执行时间)
current_connections 对应用户的当前连接数
total_connections 对应用户的历史总连接数
unique_hosts 对应用户来自不同主机(针对主机名去重)连接的数量
current_memory 对应用户的连接当前已使用的内存分配量
total_memory_allocated 对应用户的连接的历史内存分配量 
mysql> select * from user_summary limit 1 \G
*************************** 1. row ***************************
                  user: XXXX
            statements: 520988370
     statement_latency: 8.04 w
 statement_avg_latency: 9.34 ms
           table_scans: 3729186
              file_ios: 175723683186
       file_io_latency: 2.23 w
   current_connections: 27
     total_connections: 1063563
          unique_hosts: 6
        current_memory: 0 bytes
total_memory_allocated: 0 bytes
1 row in set (0.04 sec)
2.2.5.2 user_summary_by_file_io表

这个表按用户汇总了I/O的相关信息。这个表拥有如下的列：

列名 作用
user 用户
ios 总共发生了多少次I/O
io_latency I/O的延迟 
mysql> select * from user_summary_by_file_io;
+------------+-------------+------------+
| user       | ios         | io_latency |
+------------+-------------+------------+
| XXXX1      | 45364630590 | 3.92 d     |
| XXXX5      |    35400554 | 2.60 h     |
| XXXX4      |  5316048288 | 39.01 m    |
| XXXX2      |      114389 | 457.59 ms  |
| XXXX3      |         288 | 1.02 ms    |
+------------+-------------+------------+
5 rows in set (0.03 sec)
2.2.5.3 user_summary_by_file_io_type表

这个表按用户分别统计了不同类型的I/O的情况。这个表拥有如下的列：

列名 作用
user 用户
event_name I/O事件名称
total 总计发生了多少次I/O
latency 总共的I/O时延（花费的时间）
max_latency 最大I/O时延 
mysql> select * from user_summary_by_file_io_type  limit 10;
+------------+--------------------------------------+----------+-----------+-------------+
| user       | event_name                           | total    | latency   | max_latency |
+------------+--------------------------------------+----------+-----------+-------------+
| background | wait/io/file/innodb/innodb_data_file | 35139637 | 1.37 h    | 14.10 s     |
| background | wait/io/file/innodb/innodb_log_file  |   311112 | 1.25 h    | 50.59 s     |
| background | wait/io/file/sql/FRM                 |   129640 | 121.38 ms | 1.74 ms     |
| background | wait/io/file/sql/ERRMSG              |        5 | 1.24 ms   | 1.20 ms     |
| background | wait/io/file/sql/file_parser         |      350 | 760.17 us | 13.46 us    |
| background | wait/io/file/sql/binlog              |       20 | 459.69 us | 200.42 us   |
| background | wait/io/file/myisam/kfile            |       33 | 109.25 us | 12.38 us    |
| background | wait/io/file/sql/casetest            |       10 | 93.15 us  | 44.42 us    |
| background | wait/io/file/myisam/dfile            |       29 | 92.66 us  | 14.30 us    |
| background | wait/io/file/sql/binlog_index        |       20 | 84.62 us  | 39.29 us    |
+------------+--------------------------------------+----------+-----------+-------------+
10 rows in set (0.01 sec)
2.2.5.4 user_summary_by_stages表

这个表按用户分别统计阶段事件的信息。这个表拥有如下的列：

列名 作用
user 用户
event_name I/O事件名称
total 总计发生了多少次I/O
total_latency 总共的I/O时延（花费的时间）
avg_latency 平均I/O时延 
mysql> select  * from user_summary_by_stages;
+------------+-------------------------------+-------+---------------+-------------+
| user       | event_name                    | total | total_latency | avg_latency |
+------------+-------------------------------+-------+---------------+-------------+
| background | stage/innodb/buffer pool load |     1 | 18.49 s       | 18.49 s     |
| XXXXXX     | stage/sql/copy to tmp table   |  3579 | 5.96 s        | 1.66 ms     |
+------------+-------------------------------+-------+---------------+-------------+
2 rows in set (0.18 sec)
2.2.5.5 user_summary_by_statement_latency表

这个表按用户统计了语句的执行情况。这个表拥有如下的列：

列名 作用
user 用户
total 用户执行语句总数
total_latency 用户执行语句的总延迟时间
max_latency 最大延迟时间
lock_latency 锁等待时间汇总
rows_sent 总共返回了多少行的数据
rows_examined 总计从存储引擎读取了多少数据
row_affected 总计影响了多少行数据
full_scans 总计全表扫描了多少次 
mysql> select * from user_summary_by_statement_latency \G
*************************** 1. row ***************************
         user: XXXX
        total: 125928907
total_latency: 2.04 w
  max_latency: 3.57 h
 lock_latency: 16.55 m
    rows_sent: 512627430
rows_examined: 193893079249
rows_affected: 589428520
   full_scans: 981959
2.2.5.6 user_summary_by_statement_type表

按用户和语句事件类型（事件类型名称为语句事件的event_name截取最后一部分字符串，也是语句command类型字符串类似）分组的语句统计信息。这个表拥有如下的列：

列名 作用
user 用户
statement 最近执行的语句
total 用户执行语句总数
total_latency 用户执行语句的总延迟时间
max_latency 最大延迟时间
lock_latency 锁等待时间汇总
rows_sent 总共返回了多少行的数据
rows_examined 总计从存储引擎读取了多少数据
row_affected 总计影响了多少行数据
full_scans 总计全表扫描了多少次 
mysql> select * from user_summary_by_statement_type limit 10 \G
*************************** 1. row ***************************
         user: XXX
    statement: show_variables
        total: 5269
total_latency: 9.42 s
  max_latency: 13.69 ms
 lock_latency: 380.99 ms
    rows_sent: 2592348
rows_examined: 5184696
rows_affected: 0
   full_scans: 5269
*************************** 2. row ***************************
         user: XXX
    statement: show_status
        total: 5269
total_latency: 8.06 s
  max_latency: 24.84 ms
 lock_latency: 654.23 ms
    rows_sent: 1859957
rows_examined: 3719914
rows_affected: 0
   full_scans: 5269

3. 结束语

到这里，简单的介绍了下sys Schema 库相关的表。那么这些表能查询到些什么数据呢？在一篇文章中在做下介绍吧~

猜你喜欢

转载自www.cnblogs.com/bush2582/p/10201968.html
今日推荐
火速冲上 GitHub 热榜 —— 开源编程语言、框架哪有这么可爱？
北京人形机器人创新中心发布全球首个纯电驱拟人奔跑的全尺寸人形机器人“天工”
LFOSSA 源来如此公开课 | 掌握云原生未来：CNCF 认证全面攻略与备考秘籍
国产云输入法——仅华为无云端数据上传安全问题
开源日报 | 工业开源项目OGG 1.0；姐姐，你要和我一起配置火狐吗；苹果AI遥遥落后？Fedora 40
开放签电子签章：停止新增，优化体验，前进更进（五一假期前工作）
开源日报 | 中学生开源前端动画引擎；全球首个Llama3 8B中文版开源模型；联想电脑恐出局；Linus讽刺AI炒作
周排行
浏览器对同一域名进行请求的最大并发连接数
React Hook之自定义Hook
【转】MyBatis缓存机制
-Java-泛型
自动化测试常用脚本-发送邮件
LeetCode#859: Buddy Strings
java、Python处理字符串
第二篇の博客
Hadoop伪分布式环境安装
SQL Server进阶（十一）临时表、表变量
每日归档
更多
2024-04-27(56)
2024-04-26(39)
2024-04-25(22)
2024-04-24(36)
2024-04-23(26)
2024-04-22(39)
2024-04-21(0)
2024-04-20(6)
2024-04-19(5)
2024-04-18(0)

代码天地 © 2018 codetd.com

境外服务器   最新电视剧2022