MySQLInnoDB内存压力判断以及存在的疑问是怎样的

本篇文章为大家展示了MySQL InnoDB内存压力判断以及存在的疑问是怎样的，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。

10年积累的做网站、网站建设经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站设计后付款的网站建设流程，更有泉港免费网站建设让你可以放心的选择与我们合作。

与其他数据一样，内存对数据库的性能有着至关重要的影响，MySQL  InnoDB也一样通过内存来缓存数据，在访问数据的时候通过访问内存中缓存的数据来提高数据的访问效率。

MySQL中通过show variables like  'Innodb_buffer_pool%'命令或者直接访问performance_schema.global_status系统表，

可以得到数据库在运行过程中对内存或者磁盘的读取情况，根据这个数据，可以计算出来InnoDB在对数据读取过程中发生的内存或者物理磁盘读写情况，也即缓存***率。

对于“缓存***率”，在SQL Server中也有这一概念，而且含义几乎是一致的，

不过SQL Server中通过Buffer Cache hit ratio性能计数器或者  sys.dm_os_performance_counters计算出来的Buffer Cache hit ratio并不能直接反应内存压力情况，

原因归结为SQL Server在计算Buffer Cache hit  ratio的时候，是包含了预读这部分数据的(把预读部分的page也算做缓存***)，

对于MySQL的InnoDB引擎，有同样类似的逻辑读，物理读与预读的概念，因此在计算MySQL缓存***率的时候，需要靠预读这部分数据的信息。

在判定内存压力的时候，关注performance_schema.global_status中与InnoDB读写相关的参数有如下几个，这里的次数也就是MySQL存储的默认page大小，

page大小同样可以通过performance_schema.global_status 来获取，单位是字节数，默认情况下页大小是16kb

Innodb_buffer_pool_read_requests：································从缓冲池中读取的页的次数

Innodb_buffer_pool_reads：············································从物理此案读取页的次数

Innodb_buffer_pool_reads_ahead：··································预读的次数

Innodb_buffer_pool_read_ahead_evicted：························预读的页，但是没有被预读就从缓冲池中被替换的页的数量，一般用来判断预读的效率

Innodb_data_read：·······················································读取的字节数

Innodb_data_reads：······················································读取的次数

这些参数是MySQL服务器启动以来累计增加的，如果重启MySQL服务器，参数将清零从新开始累计增加。

缓冲***率理论上就是：缓冲读取次数/(缓冲读取次数+物理读取次数+预读次数)

也即：Innodb_buffer_pool_read_requests/(Innodb_buffer_pool_read_requests+Innodb_buffer_pool_reads+Innodb_buffer_pool_reads_ahead)

个人认为，这个值的实时计算结果参考意义并不大，如果直接根据查询出来的值进行计算，当前计算值反馈的是自服务启动以来的平均值。

在衡量实际压力的时候，因为数据的压力是阶段性的，需要在一定的时间段之内，按照某一个频率收集这一段时间之内，

每个时间段之内发生的逻辑读次数，物理读次数，预读次数，分别计算每个时间间隔之内的缓存***率，才具备参考意义。

可能在业务繁忙期，内存压力较大，而在空闲期压力较小，计算出来的平均值意义并不大。

另外，缓存***率只能从一个方面反映内存的压力情况，并没有一个绝对值去判断压力大还是不大。

究竟缓存***率有多高，个人认为没有一个定数，非要是99%或者某个值?主要是看与基线相比其波动情况，另外取决于具体的具体的环境。

比如对于高速存储，根据其他数据库的长期观察，由于物理存储经过优化或者本身就比较强，即便是存在一定程度的物理读，物理IO延迟不是非常长的情况下，都是可以接受的。

同时，内存压力情况也不仅仅是说“内存不足够大”，尤其是MySQL，受多种配置的影响，包括各种内存分配的大小，都会存在影响缓存***率的情况。

另外有两个实际问题，

1，MySQL在测试的时候，如何清空表(或者特定表)的缓存的数据?

2，在(重启MySQL服务)强制清空缓存之后，查询Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads，

然后查询某个物理表，再次查询Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads，发现Innodb_buffer_pool_read_requests的增幅大于Innodb_buffer_pool_reads

重启完之后，***次查询一张物理表的前后，如下截图看到的是物理读增加了2，逻辑读增加了5(测试表上没有任何索引)

继续，再次对测试的物理表进行一次查询，发现物理读没有增加(可以理解为数据被缓存了)，逻辑读增加了4(当前情况多次测试依旧是该规律)，

也就是说2次物理读缓存的数据，逻辑读每次都增加4?不太理解，这个参数具体是怎么计算出来的(很明显这里不涉及预读)。

或者说：MySQL缓存***率的计算，并非这个公式：Innodb_buffer_pool_read_requests/(Innodb_buffer_pool_read_requests+Innodb_buffer_pool_reads+Innodb_buffer_pool_reads_ahead)?

不由得想起了当时对于sqlserver缓存***率的理解，当时所有的中文资料上都说是95%什么的，中文资料基本上没有正确解读这个参数的，

实际在观察服务器参数的时候，发现实际情况跟理论根本不搭嘎，后来英文资料才发现不是这么回事。

上述内容就是MySQL InnoDB内存压力判断以及存在的疑问是怎样的，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注创新互联行业资讯频道。