mysql重要的监控参数_MYSQL 那些监控参数 之 问 答 （3） 之设计与性能

接上期

问：怎么监控InnoDB日志缓冲区,设置的是否合适

当在MySQL中对InnoDB表进行更改时，这些更改首先存储在InnoDB日志缓冲区的内存中，然后写入InnoDB日志文件，这些文件通常被称为重做日志。而如果有迹象表明innodb_log_buffer_size变量设置得太低，那么可以调整它来优化性能。

在调整之前，首先要知道当前的 innodb log buffer 到底使用了多少，我们可以使用下面的方法来进行监控

select count from information_schema.innodb_metrics where name ='log_lsn_current';

select count from information_schema.innodb_metrics where name ='log_lsn_last_flush' ;

将两个值相减，就能得到当前有多少 lsn 还没有刷入到磁盘，也就得到 innodb log buffer 使用情况。

从上边的使用量上看，进行一个时间段的评估就能知道这个服务器对应的配置是否合适。

问：在接手一个MYSQL 系统后(半路来的)，你怎么快速的通过监控来知道这个系统的关于 page  merge  page splits 的情况， 到最终的整体系统设计十分OK？  (仅作为参考和发现问题使用)

首先我们要有一个共同的共识，数据库处理数据都是在内存中处理的，而数据在内存中处理不是按照 ROW 而是按照 page 的方式来处理的。用表和行来组织数据时，InnoDB用分支、页面和记录来组织数据。记住InnoDB不能在单行的基础上工作是非常重要的。InnoDB总是对页面进行操作。加载页面后，它将扫描页面以查找请求的行/记录。

根据MERGE_THRESHOLD的值的配置情况，我们需要了解到 mysql 整体的页合并和页分离的情况。

一般来说merge_threshold 设置时 50% , 而太小的 merge_threshold 会导致在整体数据量不变化的情况下，整体的数据占用空间变大，相对的就是内存的占用会变大。

所以监控也的merge 和 split  是查看当前的 merge_threshold 十分合适以及系统整体的运行情况的一个指标(例如这个系统设计的，都是物理删，没有逻辑删，或经常UPDATE 的字段原先小，UPDATE 后都变得很大)，这样的情况

就需要看

index page merge attempts  &  index page merge successful 以及 splits

频繁的 merge 和 splits 本身就对数据库是一种性能上的影响，并且在操作过程中会影响 DML的相关操作。

另外借一篇国外文章中关于主键设计的对于页分割的影响来看，设计有缺陷的INNODB 的主键表，页splits 的操作数要比正常的，多2倍或更多。

通过这个问题，通过这个问题还可以导引出，在MYSQL 中过多的索引并由于表当初的设计的问题，会导致更差的性能问题，所以针对MYSQL 表的设对比其他的数据库设计要更严谨。

待 ...

如果有进行数据库交流的同学，可以加这个群，一起学习，群里有一些共享文件，如果需要可以自行下载