Mysql 监控 performance_schema 拿得起，放不下（2）

接上期说，在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;