接着上期sys 库的内容，sys 库的监控的内容基本上可以满足大部分对于性能分析的需求，SYS 库中的信息可以分为2种数据展示的方式，和10+种的信息展示类别。我们下面来说一说。基于ORACLE的设计理念，SYS库中的信息分为一X$为开头的VIEW的信息和以普通表名为开头的信息。两者的信息内容是相同的，展示的方式是不同的，我们基本上使用的是以普通名字开头的表，MYSQL对这些表进行了处理，方便查询者对这些信息进行阅读。

8种，主要还是从内容的类别划分，从主机层面的信息分类展示以HOST为开头， 以数据库引擎INNODB 为开头的展示了INNODB中的锁和buffer信息，以IO为开头的展示了基于IO层面的为基础的类别的信息， 还有以内存为基点的信息，以schema 为开头的针对表为原点的信息展示。以语句为隐患点的statement 信息， 以用户为基础的 user开头的信息， 和以 wait 等待为原点的信息展示。下面针对这些表调出一些十分有意义的表进行展示。

1  根据访问的主机来分析到底来自于这个主机的那个语句的或操作是耗时严重的。

select host,statement,lock_latency,format(total_latency/total,2) as single_latency_ms from host_summary_by_statement_type order by total_latency/total desc;

2  针对MYSQL系统中的每张表在INNODB  BUFFER 已经使用的缓存量前10位

 select object_schema as database_name,object_name as table_name,allocated as taken_memory from innodb_buffer_stats_by_table order by rows_cached desc limit 10;

 select object_schema as database_name,object_name as table_name,allocated as taken_memory from innodb_buffer_stats_by_table order by rows_cached desc limit 10;

3  查看INNODB 读取三种文件的延迟状态

select event_name,avg_latency,read_latency,write_latency,count_read,count_write from io_global_by_wait_by_latency where event_name in ('innodb/innodb_log_file','innodb/innodb_data_file','innodb/innodb_dblwr_file') order by total_latency desc;

4  根据语句来分析当前语句线程所分配的内存

select ps.thd_id,ps.user,ps.db,ps.command,ps.state,ps.current_statement,
ms.current_allocated,ms.total_allocated
from sys.processlist as ps
inner join sys.memory_by_thread_by_current_bytes as ms on ps.thd_id = ms.thread_id
where ms.thread_id > 50;

5  查看索引性能问题，如建立索引后，针对索引操作中的延迟问题，包含插入，更新，删除数据等等的延迟。

 select table_schema,table_name,index_name,insert_latency,update_latency from schema_index_statistics where table_schema not in ('performance_schema','information_schema','sys','mysql');

6  语句在执行过程full_scan的延迟情况

select query,full_scan,avg_latency,lock_latency,rows_sent_avg,temp_table select query,full_scan,avg_latency,lock_latency,rows_sent_avg,tmp_tables,rows_sorted from statement_analysis where full_scan = '*' order by last_seen
desc；

实际上还有很多可以进行挖掘的性能分析的内容，例如通过schema_table_statistics_with_buffer + processlist 分析整体语句和表在工作中的各种延迟以及占用的内存情况等等。

MYSQL 8 在SYS库中的改变是巨大的，通过SYS库可以快速的分析出当前MYSQL的性能问题在哪个点，哪个语句，等等如果做好历史记录，则整体的数据库细致的性能问题的曲线也能被画出。