按user分组统计视图|全方位认识sys系统库
在上一篇 《按 host 分组统计视图|全方位认识 sys 系统库》 中，我们介绍了sys 系统库中按 host 分组统计的视图，类似地，本期的内容将为大家介绍按照 user 进行分类统计的视图。下面请跟随我们一起开始 sys 系统库的系统学习之旅吧。
五通桥网站建设公司成都创新互联公司,五通桥网站设计制作，有大型网站制作公司丰富经验。已为五通桥近千家提供企业网站建设服务。企业网站搭建\外贸网站制作要多少钱，请找那个售后服务好的五通桥做网站的公司定做！
01
user_summary,x$user_summary
查看活跃连接中按用户分组的总执行时间、平均执行时间、总的IOS、总的内存使用量、表扫描数量等统计信息，默认按照总延迟时间(执行时间)降序排序。数据来源：performance_schema.accounts、sys.x$user_summary_by_statement_latency、sys.x$user_summary_by_file_io、sys.x$memory_by_user_by_current_bytes
下面我们看看使用该视图查询返回的结果。
# 不带x$前缀的视图 admin@localhost : sys 12:54:32> select * from user_summary limit 1\G *************************** 1. row *************************** user: admin statements: 90530 statement_latency: 2.09 h statement_avg_latency: 83.12 ms table_scans: 498 file_ios: 60662 file_io_latency: 31.05 s current_connections: 4 total_connections: 1174 unique_hosts: 2 current_memory: 85.34 MiB total_memory_allocated: 7.21 GiB 1 row in set (0.04 sec) # 带x$前缀的视图 admin@localhost : sys 12:55:48> select * from x$user_summary limit 1\G *************************** 1. row *************************** user: admin statements: 90752 statement_latency: 7524792139504000 statement_avg_latency: 82915992369.3583 table_scans: 500 file_ios: 60662 file_io_latency: 31053125849250 current_connections: 4 total_connections: 1174 unique_hosts: 2 current_memory: 89381384 total_memory_allocated: 7755173436 1 row in set (0.02 sec)
视图字段含义如下：
user：客户端访问用户名。如果在performance_schema表中user列为NULL，则假定为后台线程，该字段为'background',如果为前台线程，则该字段对应具体的用户名
statements：对应用户执行的语句总数量
statement_latency：对应用户执行的语句总延迟时间(执行时间)
statement_avg_latency：对应用户执行的语句中，平均每个语句的延迟时间(执行时间)(SUM(stmt.total_latency/SUM(stmt.total))
table_scans：对应用户执行的语句发生表扫描总次数
file_ios：对应用户执行的语句产生的文件I/O事件总次数
file_io_latency：对应用户执行的语句产生的文件I/O事件的总延迟时间(执行时间)
current_connections：对应用户的当前连接数
total_connections：对应用户的历史总连接数
unique_hosts：对应用户来自不同主机(针对主机名去重)连接的数量
current_memory：对应用户的连接当前已使用的内存分配量
total_memory_allocated：对应用户的连接的历史内存分配量
PS：该视图只统计文件IO等待事件信息("wait/io/file/%")
02
user_summary_by_file_io,x$user_summary_by_file_io
按照用户分组的文件I/O延迟时间、IOS统计信息，默认按照总文件I/O时间延迟时间(执行时间)降序排序。数据来源：performance_schema.events_waits_summary_by_user_by_event_name
下面我们看看使用该视图查询返回的结果。
# 不带x$前缀的视图 admin@localhost : sys 12:56:18> select * from user_summary_by_file_io limit 3; +------------+-------+------------+ | user | ios | io_latency | +------------+-------+------------+ | admin | 30331 | 15.53 s | | background | 10119 | 2.49 s | | qfsys | 281 | 4.69 ms | +------------+-------+------------+ 3 rows in set (0.01 sec) # 带x$前缀的视图 admin@localhost : sys 12:56:21> select * from x$user_summary_by_file_io limit 3; +------------+-------+----------------+ | user | ios | io_latency | +------------+-------+----------------+ | admin | 30331 | 15526562924625 | | background | 10122 | 2489231563125 | | qfsys | 281 | 4689150375 | +------------+-------+----------------+ 3 rows in set (0.00 sec)
视图字段含义如下：
user：客户端用户名。如果在performance_schema表中user列为NULL，则假定为后台线程，该字段为'background',如果为前台线程，则该字段对应具体的用户名
ios：对应用户的文件I/O事件总次数
io_latency：对应用户的文件I/O事件的总延迟时间(执行时间)
PS：该视图只统计文件IO等待事件信息("wait/io/file/%")
03
user_summary_by_file_io_type,x$user_summary_by_file_io_type
按照用户和事件类型(事件名称)分组的文件I/O延迟和IOS统计信息，默认情况下按照用户名和总文件I/O时间延迟时间(执行时间)降序排序。数据来源：performance_schema.events_waits_summary_by_user_by_event_name
下面我们看看使用该视图查询返回的结果。
# 不带x$前缀的视图 admin@localhost : sys 12:56:24> select * from user_summary_by_file_io_type limit 3; +-------+-------------------------------------+-------+---------+-------------+ | user | event_name | total | latency | max_latency | +-------+-------------------------------------+-------+---------+-------------+ | admin | wait/io/file/sql/io_cache | 27955 | 10.53 s | 67.61 ms | | admin | wait/io/file/innodb/innodb_log_file | 912 | 2.14 s | 28.22 ms | | admin | wait/io/file/sql/binlog | 879 | 2.05 s | 31.75 ms | +-------+-------------------------------------+-------+---------+-------------+ 3 rows in set (0.00 sec) # 带x$前缀的视图 admin@localhost : sys 12:56:48> select * from x$user_summary_by_file_io_type limit 3; +-------+-------------------------------------+-------+----------------+-------------+ | user | event_name | total | latency | max_latency | +-------+-------------------------------------+-------+----------------+-------------+ | admin | wait/io/file/sql/io_cache | 27955 | 10534662677625 | 67608294000 | | admin | wait/io/file/innodb/innodb_log_file | 912 | 2143870695375 | 28216455000 | | admin | wait/io/file/sql/binlog | 879 | 2054976453000 | 31745275125 | +-------+-------------------------------------+-------+----------------+-------------+ 3 rows in set (0.01 sec)
视图字段含义如下：
user：客户端用户名。如果在performance_schema表中user列为NULL，则假定为后台线程，该字段为'background',如果为前台线程，则该字段对应具体的用户名
EVENT_NAME：文件I/O事件名称
total：对应用户发生的文件I/O事件总次数
latency：对应用户的文件I/O事件的总延迟时间(执行时间)
max_latency：对应用户的单次文件I/O事件的最大延迟时间(执行时间)
PS：该视图只统计文件IO等待事件信息("wait/io/file/%")
04
user_summary_by_stages,x$user_summary_by_stages
按用户分组的阶段事件统计信息，默认情况下按照用户名和阶段事件总延迟时间(执行时间)降序排序。数据来源：performance_schema.events_stages_summary_by_user_by_event_name
下面我们看看使用该视图查询返回的结果。
# 不带x$前缀的视图 admin@localhost : sys 12:56:51> select * from user_summary_by_stages limit 3; +------------+-------------------------------+-------+---------------+-------------+ | user | event_name | total | total_latency | avg_latency | +------------+-------------------------------+-------+---------------+-------------+ | background | stage/innodb/buffer pool load | 1 | 12.56 s | 12.56 s | +------------+-------------------------------+-------+---------------+-------------+ 1 row in set (0.01 sec) # 带x$前缀的视图 admin@localhost : sys 12:57:10> select * from x$user_summary_by_stages limit 3; +------------+-------------------------------+-------+----------------+----------------+ | user | event_name | total | total_latency | avg_latency | +------------+-------------------------------+-------+----------------+----------------+ | background | stage/innodb/buffer pool load | 1 | 12561724877000 | 12561724877000 | +------------+-------------------------------+-------+----------------+----------------+ 1 row in set (0.00 sec)
视图字段含义如下：
user：客户端用户名。如果在performance_schema表中user列为NULL，则假定为后台线程，该字段为'background',如果为前台线程，则该字段对应具体的用户名
EVENT_NAME：阶段事件名称
total：对应用户的阶段事件的总次数
total_latency：对应用户的阶段事件的总延迟时间(执行时间)
avg_latency：对应用户的阶段事件的平均延迟时间(执行时间)
05
user_summary_by_statement_latency,x$user_summary_by_statement_latency
按照用户分组的语句统计信息，默认情况下按照语句总延迟时间(执行时间)降序排序。数据来源：performance_schema.events_statements_summary_by_user_by_event_name
下面我们看看使用该视图查询返回的结果。
# 不带x$前缀的视图 admin@localhost : sys 12:57:13> select * from user_summary_by_statement_latency limit 3; +------------+-------+---------------+-------------+--------------+-----------+---------------+---------------+------------+ | user | total | total_latency | max_latency | lock_latency | rows_sent | rows_examined | rows_affected | full_scans | +------------+-------+---------------+-------------+--------------+-----------+---------------+---------------+------------+ | admin | 45487 | 1.05 h | 45.66 m | 19.02 s | 6065 | 17578842 | 1544 | 258 | | qfsys | 9 | 929.43 ms | 928.68 ms | 0 ps | 5 | 0 | 0 | 0 | | background | 0 | 0 ps | 0 ps | 0 ps | 0 | 0 | 0 | 0 | +------------+-------+---------------+-------------+--------------+-----------+---------------+---------------+------------+ 3 rows in set (0.00 sec) # 带x$前缀的视图 admin@localhost : sys 12:57:34> select * from x$user_summary_by_statement_latency limit 3; +------------+-------+------------------+------------------+----------------+-----------+---------------+---------------+------------+ | user | total | total_latency | max_latency | lock_latency | rows_sent | rows_examined | rows_affected | full_scans | +------------+-------+------------------+------------------+----------------+-----------+---------------+---------------+------------+ | admin | 45562 | 3762457232413000 | 2739502018445000 | 19019928000000 | 6068 | 17579421 | 1544 | 259 | | qfsys | 9 | 929429421000 | 928682487000 | 0 | 5 | 0 | 0 | 0 | | background | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +------------+-------+------------------+------------------+----------------+-----------+---------------+---------------+------------+ 3 rows in set (0.00 sec)
视图字段含义如下：
user：客户端用户名。如果在performance_schema表中user列为NULL，则假定为后台线程，该字段为'background',如果为前台线程，则该字段对应具体的用户名
total：对应用户执行的语句总数量
total_latency：对应用户执行的语句总延迟时间(执行时间)
max_latency：对应用户执行的语句单次最大延迟时间(执行时间)
lock_latency：对应用户执行的语句锁等待的总时间
rows_sent：对应用户执行的语句返回给客户端的总数据行数
rows_examined：对应用户执行的语句从存储引擎读取的总数据行数
rows_affected：对应用户执行的语句影响的总数据行数
full_scans：对应用户执行的语句的全表扫描总次数
06
user_summary_by_statement_type,x$user_summary_by_statement_type
按用户和语句事件类型（事件类型名称为语句事件的event_name截取最后一部分字符串，也是语句command类型字符串类似）分组的语句统计信息，默认情况下按照用户名和对应语句的总延迟时间(执行时间)降序排序。数据来源：performance_schema.events_statements_summary_by_user_by_event_name
下面我们看看使用该视图查询返回的结果。
# 不带x$前缀的视图 admin@localhost : sys 12:57:38> select * from user_summary_by_statement_type limit 3; +-------+-------------+-------+---------------+-------------+--------------+-----------+---------------+---------------+------------+ | user | statement | total | total_latency | max_latency | lock_latency | rows_sent | rows_examined | rows_affected | full_scans | +-------+-------------+-------+---------------+-------------+--------------+-----------+---------------+---------------+------------+ | admin | alter_table | 2 | 56.56 m | 43.62 m | 0 ps | 0 | 0 | 0 | 0 | | admin | select | 3662 | 5.53 m | 2.02 m | 4.73 s | 6000 | 17532984 | 0 | 148 | | admin | insert | 1159 | 36.04 s | 337.22 ms | 14.23 s | 0 | 0 | 1159 | 0 | +-------+-------------+-------+---------------+-------------+--------------+-----------+---------------+---------------+------------+ 3 rows in set (0.00 sec) # 带x$前缀的视图 admin@localhost : sys 12:57:50> select * from x$user_summary_by_statement_type limit 3; +-------+-------------+-------+------------------+------------------+----------------+-----------+---------------+---------------+------------+ | user | statement | total | total_latency | max_latency | lock_latency | rows_sent | rows_examined | rows_affected | full_scans | +-------+-------------+-------+------------------+------------------+----------------+-----------+---------------+---------------+------------+ | admin | alter_table | 2 | 3393877088372000 | 2617456143674000 | 0 | 0 | 0 | 0 | 0 | | admin | select | 3663 | 331756087959000 | 121243627173000 | 4733109000000 | 6003 | 17533557 | 0 | 149 | | admin | insert | 1159 | 36041502943000 | 337218573000 | 14229439000000 | 0 | 0 | 1159 | 0 | +-------+-------------+-------+------------------+------------------+----------------+-----------+---------------+---------------+------------+ 3 rows in set (0.00 sec)
视图字段含义如下：
user：客户端用户名。如果在performance_schema表中user列为NULL，则假定为后台线程，该字段为'background',如果为前台线程，则该字段对应具体的用户名
statement：语句事件名称的最后一部分字符串，与语句的command类型字符串类似
其他字段含义与 user_summary_by_statement_latency,x$user_summary_by_statement_latency 视图的字段含义相同
本期内容就介绍到这里，本期内容参考链接如下：
https://dev.MySQL.com/doc/refman/5.7/en/sys-user-summary-by-statement-type.html
https://dev.mysql.com/doc/refman/5.7/en/sys-user-summary-by-file-io.html
https://dev.mysql.com/doc/refman/5.7/en/sys-user-summary-by-file-io-type.html
https://dev.mysql.com/doc/refman/5.7/en/sys-user-summary-by-stages.html
https://dev.mysql.com/doc/refman/5.7/en/sys-user-summary-by-statement-latency.html
https://dev.mysql.com/doc/refman/5.7/en/sys-user-summary.html
| 作者简介
罗小波·沃趣科技高级数据库技术专家
IT从业多年，历任运维工程师，高级运维工程师，运维经理，数据库工程师，曾参与版本发布系统，轻量级监控系统，运维管理平台，数据库管理平台的设计与编写，熟悉MySQL的体系结构时，InnoDB存储引擎，喜好专研开源技术，追求完美。
网站栏目：按user分组统计视图|全方位认识sys系统库
本文路径：http://myzitong.com/article/ijpoeo.html