共计 2850 个字符，预计需要花费 8 分钟才能阅读完成。
与其他数据一样，内存对数据库的性能有着至关重要的影响，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 存储引擎
https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_buffer_pool_size
https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-resize.html#innodb-buffer-pool-online-resize
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-07/145998.htm
