接上期说，在MYSQL 5.7 后performance_schema 以及后来的sys库的重要性越来越高，各种系统的性能以及系统资源的分配信息都会在这里体现。
例1
select event_name,current_number_of_bytes_used/1024/1024 as current_number_of_MB_used
from performance_schema.memory_summary_global_by_event_name where event_name = 'memory/innodb/buf_buf_pool';
select *
from sys.memory_global_by_current_bytes where event_name = 'memory/innodb/buf_buf_pool';
实际上大家可以从上面的两个语句看出输出的内容基本是一致的，sys库可以看做是一个更人性化提供信息的库，信息来自performance_schema , information_schema 两个库中。
实际上也是这样，通过查看`sys`.`memory_global_by_current_bytes` 这个VIEW 要和可以看出的确是这样的。
'CREATE VIEW `sys`.`memory_global_by_current_bytes` (`event_name`,`current_count`,`current_alloc`,`current_avg_alloc`,`high_count`,`high_alloc`,`high_avg_alloc`) AS select `performance_schema`.`memory_summary_global_by_event_name`.`EVENT_NAME` AS `event_name`,`performance_schema`.`memory_summary_global_by_event_name`.`CURRENT_COUNT_USED` AS `current_count`,
`sys`.`format_bytes`(`performance_schema`.`memory_summary_global_by_event_name`.`CURRENT_NUMBER_OF_BYTES_USED`) AS `current_alloc`,
`sys`.`format_bytes`(ifnull((`performance_schema`.`memory_summary_global_by_event_name`.`CURRENT_NUMBER_OF_BYTES_USED` nullif(`performance_schema`.`memory_summary_global_by_event_name`.`CURRENT_COUNT_USED`,0)),0)) AS `current_avg_alloc`,
`performance_schema`.`memory_summary_global_by_event_name`.`HIGH_COUNT_USED` AS `high_count`,
`sys`.`format_bytes`(`performance_schema`.`memory_summary_global_by_event_name`.`HIGH_NUMBER_OF_BYTES_USED`) AS `high_alloc`,
`sys`.`format_bytes`(ifnull((`performance_schema`.`memory_summary_global_by_event_name`.`HIGH_NUMBER_OF_BYTES_USED` nullif(`performance_schema`.`memory_summary_global_by_event_name`.`HIGH_COUNT_USED`,0)),0)) AS `high_avg_alloc`
from `performance_schema`.`memory_summary_global_by_event_name`
where (`performance_schema`.`memory_summary_global_by_event_name`.`CURRENT_NUMBER_OF_BYTES_USED` > 0)
order by `performance_schema`.`memory_summary_global_by_event_name`.`CURRENT_NUMBER_OF_BYTES_USED` desc'
例2
SELECT seh.digest_text
, ses.count_star
, ses.avg_timer_wait 1000000000000
,ses.digest
FROM performance_schema.events_statements_summary_by_digest as ses
inner join performance_schema.events_statements_history as seh on ses.digest = seh.digest
ORDER BY avg_timer_wait DESC
LIMIT 1;
实际上这里为什么要卷 performance_schema.events_statements_history，主要还是因为performance_schema.events_statements_summary_by_digest 在展现语句上，截取了语句，所以通过events_statements_history，来讲不被截取的语句进行展现。
例3 如果要对当前的select 信息进行一个统计分析，比如根据从访问是从哪来来的，来看看当前select 查询的情况，包含延迟，通过这些信息信息，稍加加工，你就可以对当前的系统进行一个整体的画像，例如每5 - 10 秒将信息以折线的方式来展示点，通过这些点来看到系统整体的变化，例如在那个时间点变化比较大，或者在新系统上线后，数据库的变化等等，这些都是对运维有帮助的信息。
SELECT * FROM sys.host_summary_by_statement_type where statement in ('select'); 但这些信息也是从performance_schema来的，只不过在sys库进行了一次封装。
例4 如果是使用mysql 老手，一定不会忘记分析mysql性能的 profiling ，在MYSQL 5.7 后这个功能已经慢慢被 performance_schema 里面的表淡化了
举例我们查询了一些语句，并且对他们的在语句执行期间的状态和每个步骤都比较感兴趣。
通过 events_statements_history_long 来查询语句的event_id
SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6) as Duration, SQL_TEXT
FROM performance_schema.events_statements_history_long WHERE SQL_TEXT like '%test_mgr.test_p%';
通过event_id 在 event_stages_history_long 中查询相关语句的执行步骤
SELECT event_name AS Stage, TRUNCATE(TIMER_WAIT/1000000000000,6) AS Duration
FROM performance_schema.events_stages_history_long WHERE NESTING_EVENT_ID=43970;
例5 在mysql 中使用MGR 中，重要的节点是要确认，当前的MGR中那个是primary 库，（多主模式请略过），如果能判断出主库，则进行相关的IP 对DNS 的转换，就可以程序化，达到对应用的透明切换主节点的工作。
SELECT pg.variable_value,pr.member_host,pr.member_state,pr.member_role
FROM performance_schema.global_status as pg
JOIN performance_schema.replication_group_members as pr
WHERE variable_name = 'group_replication_primary_member'
AND member_id=variable_value;
电子书可以入群自取
