MySQL InnoDB內(nèi)存壓力判斷以及存在的疑問是怎樣的

本篇文章為大家展示了MySQL InnoDB內(nèi)存壓力判斷以及存在的疑問是怎樣的，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

與其他數(shù)據(jù)一樣，內(nèi)存對數(shù)據(jù)庫的性能有著至關(guān)重要的影響，MySQL  InnoDB也一樣通過內(nèi)存來緩存數(shù)據(jù)，在訪問數(shù)據(jù)的時候通過訪問內(nèi)存中緩存的數(shù)據(jù)來提高數(shù)據(jù)的訪問效率。

MySQL中通過show variables like  'Innodb_buffer_pool%'命令或者直接訪問performance_schema.global_status系統(tǒng)表，

可以得到數(shù)據(jù)庫在運(yùn)行過程中對內(nèi)存或者磁盤的讀取情況，根據(jù)這個數(shù)據(jù)，可以計算出來InnoDB在對數(shù)據(jù)讀取過程中發(fā)生的內(nèi)存或者物理磁盤讀寫情況，也即緩存***率。

對于“緩存***率”，在SQL Server中也有這一概念，而且含義幾乎是一致的，

不過SQL Server中通過Buffer Cache hit ratio性能計數(shù)器或者  sys.dm_os_performance_counters計算出來的Buffer Cache hit ratio并不能直接反應(yīng)內(nèi)存壓力情況，

原因歸結(jié)為SQL Server在計算Buffer Cache hit  ratio的時候，是包含了預(yù)讀這部分?jǐn)?shù)據(jù)的(把預(yù)讀部分的page也算做緩存***)，

對于MySQL的InnoDB引擎，有同樣類似的邏輯讀，物理讀與預(yù)讀的概念，因此在計算MySQL緩存***率的時候，需要靠預(yù)讀這部分?jǐn)?shù)據(jù)的信息。

在判定內(nèi)存壓力的時候，關(guān)注performance_schema.global_status中與InnoDB讀寫相關(guān)的參數(shù)有如下幾個，這里的次數(shù)也就是MySQL存儲的默認(rèn)page大小，

page大小同樣可以通過performance_schema.global_status 來獲取，單位是字節(jié)數(shù)，默認(rèn)情況下頁大小是16kb

Innodb_buffer_pool_read_requests：································從緩沖池中讀取的頁的次數(shù)

Innodb_buffer_pool_reads：············································從物理此案讀取頁的次數(shù)

Innodb_buffer_pool_reads_ahead：··································預(yù)讀的次數(shù)

Innodb_buffer_pool_read_ahead_evicted：························預(yù)讀的頁，但是沒有被預(yù)讀就從緩沖池中被替換的頁的數(shù)量，一般用來判斷預(yù)讀的效率

Innodb_data_read：·······················································讀取的字節(jié)數(shù)

Innodb_data_reads：······················································讀取的次數(shù)

這些參數(shù)是MySQL服務(wù)器啟動以來累計增加的，如果重啟MySQL服務(wù)器，參數(shù)將清零從新開始累計增加。

緩沖***率理論上就是：緩沖讀取次數(shù)/(緩沖讀取次數(shù)+物理讀取次數(shù)+預(yù)讀次數(shù))

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

個人認(rèn)為，這個值的實(shí)時計算結(jié)果參考意義并不大，如果直接根據(jù)查詢出來的值進(jìn)行計算，當(dāng)前計算值反饋的是自服務(wù)啟動以來的平均值。

在衡量實(shí)際壓力的時候，因為數(shù)據(jù)的壓力是階段性的，需要在一定的時間段之內(nèi)，按照某一個頻率收集這一段時間之內(nèi)，

每個時間段之內(nèi)發(fā)生的邏輯讀次數(shù)，物理讀次數(shù)，預(yù)讀次數(shù)，分別計算每個時間間隔之內(nèi)的緩存***率，才具備參考意義。

可能在業(yè)務(wù)繁忙期，內(nèi)存壓力較大，而在空閑期壓力較小，計算出來的平均值意義并不大。

另外，緩存***率只能從一個方面反映內(nèi)存的壓力情況，并沒有一個絕對值去判斷壓力大還是不大。

究竟緩存***率有多高，個人認(rèn)為沒有一個定數(shù)，非要是99%或者某個值?主要是看與基線相比其波動情況，另外取決于具體的具體的環(huán)境。

比如對于高速存儲，根據(jù)其他數(shù)據(jù)庫的長期觀察，由于物理存儲經(jīng)過優(yōu)化或者本身就比較強(qiáng)，即便是存在一定程度的物理讀，物理IO延遲不是非常長的情況下，都是可以接受的。

同時，內(nèi)存壓力情況也不僅僅是說“內(nèi)存不足夠大”，尤其是MySQL，受多種配置的影響，包括各種內(nèi)存分配的大小，都會存在影響緩存***率的情況。

另外有兩個實(shí)際問題，

1，MySQL在測試的時候，如何清空表(或者特定表)的緩存的數(shù)據(jù)?

2，在(重啟MySQL服務(wù))強(qiáng)制清空緩存之后，查詢Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads，

然后查詢某個物理表，再次查詢Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads，發(fā)現(xiàn)Innodb_buffer_pool_read_requests的增幅大于Innodb_buffer_pool_reads

重啟完之后，***次查詢一張物理表的前后，如下截圖看到的是物理讀增加了2，邏輯讀增加了5(測試表上沒有任何索引)

繼續(xù)，再次對測試的物理表進(jìn)行一次查詢，發(fā)現(xiàn)物理讀沒有增加(可以理解為數(shù)據(jù)被緩存了)，邏輯讀增加了4(當(dāng)前情況多次測試依舊是該規(guī)律)，

也就是說2次物理讀緩存的數(shù)據(jù)，邏輯讀每次都增加4?不太理解，這個參數(shù)具體是怎么計算出來的(很明顯這里不涉及預(yù)讀)。

或者說：MySQL緩存***率的計算，并非這個公式：Innodb_buffer_pool_read_requests/(Innodb_buffer_pool_read_requests+Innodb_buffer_pool_reads+Innodb_buffer_pool_reads_ahead)?

不由得想起了當(dāng)時對于sqlserver緩存***率的理解，當(dāng)時所有的中文資料上都說是95%什么的，中文資料基本上沒有正確解讀這個參數(shù)的，

實(shí)際在觀察服務(wù)器參數(shù)的時候，發(fā)現(xiàn)實(shí)際情況跟理論根本不搭嘎，后來英文資料才發(fā)現(xiàn)不是這么回事。

上述內(nèi)容就是MySQL InnoDB內(nèi)存壓力判斷以及存在的疑問是怎樣的，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注億速云行業(yè)資訊頻道。