本文出處：http://www.cnblogs.com/wy123/p/7259866.html（保留出處並非什麼原創作品權利，本人拙作還遠遠達不到，僅僅是為了鏈接到原文，因為後續對可能存在的一些錯誤進行修正或補充，無他） 與其他數據一樣，記憶體對資料庫的性能有著至關重要的影響，MySQL InnoD ...
本文出處：http://www.cnblogs.com/wy123/p/7259866.html
（保留出處並非什麼原創作品權利，本人拙作還遠遠達不到，僅僅是為了鏈接到原文，因為後續對可能存在的一些錯誤進行修正或補充，無他）
與其他數據一樣，記憶體對資料庫的性能有著至關重要的影響，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緩存命中率的時候，需要靠預讀這部分數據的信息。
對於SQL Server之前關註過這個知識點http://www.cnblogs.com/wy123/p/5272675.html
在判定記憶體壓力的時候，關註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
