MYSQL PMM2 监控中部分参数是怎么获得的，及从中的思考

接上期,上期大致说了一下PMM2 没有任何技术含量,今天在上期没有影响的肥宅水后,需要来一点"粗粮"调理一下脑子上的电极.

我们先理一理到底为什么要关注MYSQL的内存以及关注了后又可以做什么简单一句话,懂得当前MYSQL的内存的消耗点在哪里,如果你是高手,通过消耗点你就可以知道架设在你脑袋上的应用是什么"妖精" 变化而来的,是冥王星还是天王星,然后就可以顺腾摸瓜,要比可以调整自己的MYSQL的配置,要不就可以调整一下开发的brain.

如果你是从MYSQL 5.0过来的就可以理解获知MYSQL的系统的性能的数据有多难. 从MYSQL 8 以后尤其是有了sys库后,我们的工作变得容易多了,memory_global_by_cunrrent_bytes 表能将我们的需要的数据直接进行展示.

当然也可以从连接的角度来查看内存的消耗到底有多少.

在或者从线程的角度来看

以上的参数是比较好查询的,而PMM2 中的有些查询显示的数字,要搞清楚可能要费点劲

这里面的buffer pool activity  到底是怎么换算出当前的BUFFER POOL 中的活跃的操作数?   实际上这个参数的获得就是，5秒钟获取 innodb_buffer_pool_write_requests 参数然后进行相减在除5 得到的数字，也就是平均每秒在buffer pool 中活跃的OPS 

计算当前在MYSQL 的INNODB BUFFER 中到底有多少数据，通过我们设置的INNODB_BUFFER 和 innodb_buffer_pool_page_data  之间的比较，获得当前内存中有多少数据的百分比

同样innodb_buffer_pool_page_dirty 则是通过同样的方式，用innodb_buffer_pool_pages_dirty 来获得的数据

类似redo log space 的监控的原理可以总结为通过 ，innodb_os_log_written /  innodb_log_files_in_group * innodb_log_file_size  来获得如下的redo log  消耗的信息。

 或者例如 row lock wait 中的 lock waits 

通过 Innodb_row_lock_waits 来获得相关的信息

当然我们也可以创造出一些自己的参数如，我们将下面的数据自己定义一下

如一个数据库中插入的行数和读的行数对比，如果写多读少，则证明这个数据库系统可能是服务于日志系统，或者读多写少，这个系统可能是正牌的OLTP的业务系统，在或者delete 多 UPDATE 多， 那就的好好看看这个系统的业务逻辑以及开发的操作方法，一连串的就是你的系统的UNDO REDO 的空间，以及I/O是否跟得上这样的设计，是不是可以有优化的余地等等。

实际上一个从一个监控系统中获得信息然后思考的LEVEL 个人认为会分以下几个等级

1  单纯看报警，只有报警了才去处理，这是下等，这就如同人类社会的刑法，触犯了低级的不能触犯的东西，必须立即处理，否则就可能让系统处于无法工作的情况。

2  分析系统的历史曲线，通过定期查看系统运行的历史曲线，从中发现数据库可以调整和优化的点，应对未来可能遇到的性能问题，这是中层

3  通过系统给出的监控指标，举一反三，几个指标组合后，有更深层次的分析，通过监控就看透这个系统可能在当初设计中的缺陷，并且由此想到一些通过数据库可以进行弥补的措施， 此为上等

要达到某个需求层次，应该是理解数据库原理， +  理解各个监控参数涉及的性能点 + 理解业务 = 可以发现当下系统的性能问题，并给出解决方案+针对当然的问题，给出系统设计中，在使用数据库中的设计优化点。