[[199034]]

與其他數據一樣，內存對數據庫的性能有著至關重要的影響，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%什么的，中文資料基本上沒有正確解讀這個參數的，

實際在觀察服務器參數的時候，發現實際情況跟理論根本不搭嘎，后來英文資料才發現不是這么回事。