[[199034]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這些參數(shù)是MySQL服務(wù)器啟動(dòng)以來(lái)累計(jì)增加的，如果重啟MySQL服務(wù)器，參數(shù)將清零從新開(kāi)始累計(jì)增加。

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

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

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

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

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

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

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

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

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

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

另外有兩個(gè)實(shí)際問(wèn)題，

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

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

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

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

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

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

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

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

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