MYSQL 从performance_schema说起，但不止于PS ，sys库可以成为语句分析的AWS吗？（3)...

继续前两期，从performance_schema 中的一些细节，对MYSQL 8 开展性能分析的话题说起， 这是一个系列，对此感兴趣的同学可以在文字的下方找到之前的话题。 

本期开始从MYSQL的 SYS 库开始了，实际上SYS 库的开发是基于监控的思路引入的，之前MYSQL 5.X 被诟病的监控难的问题，在MYSQL 8 已经不复存在了，如果你还抱着你的MYSQL 5.7 你会发现，你对于MYSQL 已经OUT 了，或许说你根本就不会监控了，也不见得是一个笑话。

sys 库本身起源很早,在MYSQL 5.6 就已经通过插入的方式存在了，MYSQL 5.7 也是，从8.018 后sys schema 已经融入了MYSQL 本身的系统当中，所以操控MYSQL 尤其是MYSQL8 ，sys库的理解是一个必需品。

针对SYS 库的配置信息可以从sys.sys_config 中获得信息，需要注意的是，这里sys库中的配置并不是第一个被使用的，在MYSQL中还有与之配对的变量信息，系统会先读取变量信息，如果变量信息与sys_config 的信息不匹配，会以变量信息为准。

通过下面的方式可以直接查询config 中对应的变量，如果为null 说明变量并未赋值，系统会读取config 中的值。

这里最常修改的是statement_truncate_len  ,对于收集的信息肯能由于长度的不同导致无法正常显示，所以这个选择项可能会被调整，也可以变量调整。

update sys.sys_config set value = 128 where variable = 'statement_truncate_len' ;

这里仅提两个针对我们系统性能分析中关于语句的分析中有用的两个配置项，

statement_performance_analyzer.view

statement_performance_analyzer.limit

这个本身就要往深入里面说了，所以SYS 库的问题一期是说不完了，下面就开始下探到 statement_performance_analyzer() , 这个存储过程主要的作用就是馋死一个关于在MYSQL 服务器上执行语句的报告。

关于这个存储过程中的参数包含，snapshot ， overall,   delta,  

create_tmp,  create_table , save ,cleanup

通过这个命令可以快速的获取 event_statements_summary_by_digest中的内容，通过做SNAPSHOT的方式，将表的信息写入snapshot 的表中。

命令中包含了，三个参数序列，动作，提取数据目的地，展示方式

下面我们就来做一个相关的练习

我们的目的，定期的截取MYSQL 8 数据库中的语句分析信息，并且将他们永久的存储，并定期分析这些语句的问题。

1  我们在我们设定的一个数据库里面创建一个临时表，并且通过临时表来记录我们的系统中的语句分析信息。

create database  statement_analyze;
use statement_analyze
CALL sys.statement_performance_analyzer('create_tmp', 'statement_analyze.tmp_digests', NULL);

我们在 statement_analyze 数据库中建立了一个临时表，tmp_digests

此时我们建立一个基于当前系统的语句分析的 snapshot ,并将结果存储到临时表中。

CALL sys.statement_performance_analyzer('snapshot', NULL, NULL);

CALL sys.statement_performance_analyzer('save', 'statement_analyze.tmp_digests', NULL);

在获得数据后，我们就可以通过临时表来进行当前语句的数据分析，比如那些语句是最近的 TOP10 ，等等一些在传统数据库上可以做的事情，这里都可以做。

select SCHEMA_NAME,DIGEST_TEXT,sys.format_time(MAX_TIMER_WAIT),sys.format_time(QUANTILE_95),SUM_ROWS_EXAMINED,LAST_SEEN from statement_analyze.tmp_digests order by last_seen desc limit 2 \G

然后我们可以每一个小时分析一次语句的性能状态与上一个小时的变化，

在一个小时后，我们再次执行

CALL sys.statement_performance_analyzer('snapshot', NULL, NULL);

CALL sys.statement_performance_analyzer('overall', NULL, 'with_runtimes_in_95th_percentile');

'with_runtimes_in_95th_percentile');

通过定期分析可以将当前的一些语句的运行情况进行展示和分析。下方是针对

with_runtimes_in_95th_percentile:

使用statements_with_runtimes_in_95th_percentile视图

analysis:

使用statement_analysis视图

with_errors_or_warnings：

使用statements_with_errors_or_warnings视图

with_full_table_scans:

使用 statements_with_full_table_scans视图.

with_sorting:

使用statements_with_sorting视图

with_temp_tables:

使用statements_with_temp_tables视图

下面我们对于全表扫描的问题进行处理

CALL sys.statement_performance_analyzer('delta', 'statement_analyze.tmp_digests', 'with_full_table_scans');

在操作完毕后，直接去我们的sys 库 中的表

select * from statements_with_full_table_scans order by last_seen,total_latency desc limit 2\G

写到这里，其实基于上方的一些东西和选项，可以针对MYSQL 8 开始准备开发一个新的基于MYSQL的  语句分析多维度的  "AWS" 系统了,基础MYSQL 已经在sys 库已经给你搭建好了，剩下的就是知识+ACTION ，MYSQL 8 将无疑是 MYSQL 历史上最好管理的MYSQL 系统，一点都不会差于其他的数据库系统。

下期会继续在SYS库继续一些监控的内容
————————————————

往期内容

MYSQL 从performance_schema说起，但不止于PS （2）

https://mp.weixin.qq.com/s?__biz=Mzg4NDA0NTEwNA==&mid=2247494586&idx=1&sn=bb38f225060595fa19ff3e98e0835fed&chksm=cfbc8fe5f8cb06f316065573e52218563d51b645c3df5b84581bb0d461db255b3034663cfa33&token=959999716&lang=zh_CN#rd

MYSQL 从performance_schema说起，但不止于PS （1）

https://mp.weixin.qq.com/s?__biz=Mzg4NDA0NTEwNA==&mid=2247494482&idx=1&sn=c6fd81b9a6303df9285147d9b87df5cd&chksm=cfbc8f0df8cb061b019945d3d523bb32f563edde3b2914a907e571a09461668a9b5f60561bda&token=1980463622&lang=zh_CN#rd