MySQL sys Schema 简单介绍-1
参考文档：
- MySQL- 5.7 sys schema笔记
- MySQL 5.7新特性：SYS库详解
- MySQL Performance Schema&sys Schema介绍
- 内存分配统计视图 | 全方位认识 sys 系统库
- MySQL sys Schema
- 初相识 | 全方位认识sys系统库
- 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
那么这两种形式的视图有什么不同呢？
- 以字母开头的视图是经过转换后，便于人类阅读的形式。
- 以 "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开头的视图 | 线程相关的信息(包含内部线程及用户连接） |
接下来将介绍几个使用比较多的视图：
- host 开头的视图
- user开头的视图
- innodb开头的视图
- io开头的视图
- 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
其他几个相关的表，结构和作用都差不多，不过从其他的层面进行统计，这里就不多做介绍了：
- memory_by_thread_by_current_bytes
- memory_by_user_by_current_bytes
- memory_global_by_current_bytes
- 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 库相关的表。那么这些表能查询到些什么数据呢？在一篇文章中在做下介绍吧~
编程光~
