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 库相关的表。那么这些表能查询到些什么数据呢?在一篇文章中在做下介绍吧~
MySQL sys Schema 简单介绍-1的更多相关文章
- MySQL  sys Schema 简单介绍-2
		
之前在<MySQL sys Schema 简单介绍-1>中简单的介绍了,sys Schema库中的表.那么这些表都可以查询些什么信息呢?接下来本文将做下介绍. 1. 表的情况 1.1 统计 ...
 - MySQL sys Schema
		
MySQL sys Schema 使用sys Schema的先决条件 使用sys Schema sys Schema Progress Reporting sys Schema Object Refe ...
 - Mysql数据库的简单介绍与入门
		
Mysql数据库的简单介绍与入门 前言 一.下载与安装 1.下载 官网下载MYSQL5.7.21版本,链接地址https://www.mysql.com/downloads/.下载流程图如下: 找到M ...
 - 带你认识MySQL sys schema
		
前言: MySQL 5.7中引入了一个新的sys schema,sys是一个MySQL自带的系统库,在安装MySQL 5.7以后的版本,使用mysqld进行初始化时,会自动创建sys库. sys库里 ...
 - MySQL存储引擎简单介绍
		
MySQL使用的是插件式存储引擎. 主要包含存储引擎有:MyISAM,Innodb,NDB Cluster,Maria.Falcon,Memory,Archive.Merge.Federated. 当 ...
 - MySQL主从同步简单介绍&配置
		
介绍: 现在mysql集群基本上都是使用一主多从方式,实现读写分离(主库写.从库读).负载均衡.数据备份,以前只是使用从未配置过,今天简单配置一下! mysql主从复制是通过binary log日志实 ...
 - 一、mysql分表简单介绍
		
一.Mysql分表的原因 1.当一张的数据达到几百万时,你查询一次所花的时间会变多,如果有联合查询的话,我想有可能会死在那儿了. 分表的目的就在于此,减小数据库的负担,缩短查询时间. 2.mysql中 ...
 - Mysql索引优化简单介绍
		
一.关于MySQL联合索引 总结记录一下关于在MySQL中使用联合索引的注意事项. 如:索引包含表中每一行的last_name.first_name和dob列,即key(last_name, firs ...
 - mysql sys table
		
本文详细地介绍了MySQL 5.7新引入的sys schema.首先,本文概要地介绍了sys schema的作用和定位:其次,分别介绍了sys schema中的视图.函数和存储过程:接下来,通过两个例 ...
 
随机推荐
- Something write in FSE 2014
			
Now, I find a problem, I have become my personal CSDN into a personal electronic diary. Actually, th ...
 - H3C交换机配置ACL禁止vlan间互访
			
1.先把基础工作做好,就是配置VLAN,配置Trunk,确定10个VLAN和相应的端口都正确.假设10个VLAN的地址分别是192.168.10.X,192.168.20.X......192.168 ...
 - QRCode二维码生成方案及其在带LOGO型二维码中的应用(1)
			
原文:QRCode二维码生成方案及其在带LOGO型二维码中的应用(1) 提要:很多公司为商业宣传之需,常将企业LOGO加入二维码中,但如果LOGO遮挡区域足够地大,二维码就变得无法识别.那么,有没有一 ...
 - 反编译 war 包成传统项目的方法
			
需求 项目老大让外包做了官网,不甚满意,想自己搞搞,遂叫我反编译他们发过来的 war 包. 方法 第一步:解压 war 包其实就是 zip 压缩包,用 zip 解压. 第二步:反编译 查看 war 包 ...
 - C#原子性运算 interlocked.compareExchanged
			
缘起: 假设有一个类myClass, myclass里有一个count属性. 在多线程的环境下 每个线程中 直接使用count++, 如果两个线程并行执行时, 两个线程中的一个的结果会被覆掉, 非线 ...
 - 零元学Expression Blend 4 - Chapter 46 三分钟快速充电-设定Margin的小撇步
			
原文:零元学Expression Blend 4 - Chapter 46 三分钟快速充电-设定Margin的小撇步 如果需要经常的使用某一项工具,总会希望能够更快速的使用各项设定达到效果 今天要介绍 ...
 - Android零基础入门第68节:完善RecyclerView,添加首尾视图
			
在之前学习ListView的时候,有学习过如何给ListView添加列表头和列表尾.但是通过近几期的学习,发现RecyclerView是一个比ListView更加强大和灵活的组件,今天一起来学习如何给 ...
 - 理解typedef(转)
			
// 从别人那转的,调整下格式便于阅读. 首先请看看下面这两句: typedef ]; typedef void (*p)(void); 如果你能一眼就看出它们的意思,那请不要再往下看了.如果你不太理 ...
 - Play Framework 模板里使用注入访问数据层
			
从Play2.4开始,推荐使用依赖注入替代静态控制器.因此我们不能像play2.3那样,在模板里直接调用object访问数据层.是的,我们还是可以使用常规方式,通过传参到模板里.不过这样很多时候不方便 ...
 - Delphi检测用户是否具有administrator权限(OpenThreadToken,OpenProcessToken,GetTokenInformation,AllocateAndInitializeSid和EqualSid)
			
检测用户是否具有administrator权限const SECURITY_NT_AUTHORITY: TSIDIdentifierAuthority = (Value: (0, 0, 0, 0, 0 ...