与其他数据一样，内存对数据库的性能有着至关重要的影响，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)
个人认为，这个值的实时计算结果参考意义并不大，如果直接根据查询出来的值进行计算，当前计算值反馈的是自服务启动以来的平均值。
在衡量实际压力的时候，因为数据的压力是阶段性的，需要在一定的时间段之内，按照某一个频率收集这一段时间之内，
每个时间段之内发生的逻辑读次数，物理读次数，预读次数，分别计算每个时间间隔之内的缓存命中率，才具备参考意义。
可能在业务繁忙期，内存压力较大，而在空闲期压力较小，计算出来的平均值意义并不大。