MYSQL中監(jiān)控參數(shù)的示例分析

這篇文章主要介紹了MYSQL中監(jiān)控參數(shù)的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

問：怎么監(jiān)控InnoDB日志緩沖區(qū),設(shè)置的是否合適

當(dāng)在MySQL中對InnoDB表進(jìn)行更改時，這些更改首先存儲在InnoDB日志緩沖區(qū)的內(nèi)存中，然后寫入InnoDB日志文件，這些文件通常被稱為重做日志。而如果有跡象表明innodb_log_buffer_size變量設(shè)置得太低，那么可以調(diào)整它來優(yōu)化性能。

在調(diào)整之前，首先要知道當(dāng)前的 innodb log buffer 到底使用了多少，我們可以使用下面的方法來進(jìn)行監(jiān)控

select count from information_schema.innodb_metrics where name ='log_lsn_current'; 

select count from information_schema.innodb_metrics where name ='log_lsn_last_flush' ;

將兩個值相減，就能得到當(dāng)前有多少 lsn 還沒有刷入到磁盤，也就得到 innodb log buffer 使用情況。

從上邊的使用量上看，進(jìn)行一個時間段的評估就能知道這個服務(wù)器對應(yīng)的配置是否合適。

問：在接手一個MYSQL 系統(tǒng)后（半路來的），你怎么快速的通過監(jiān)控來知道這個系統(tǒng)的關(guān)于 page  merge  page splits 的情況， 到最終的整體系統(tǒng)設(shè)計十分OK？  （僅作為參考和發(fā)現(xiàn)問題使用）

首先我們要有一個共同的共識，數(shù)據(jù)庫處理數(shù)據(jù)都是在內(nèi)存中處理的，而數(shù)據(jù)在內(nèi)存中處理不是按照 ROW 而是按照 page 的方式來處理的。用表和行來組織數(shù)據(jù)時，InnoDB用分支、頁面和記錄來組織數(shù)據(jù)。記住InnoDB不能在單行的基礎(chǔ)上工作是非常重要的。InnoDB總是對頁面進(jìn)行操作。加載頁面后，它將掃描頁面以查找請求的行/記錄。

根據(jù)MERGE_THRESHOLD的值的配置情況，我們需要了解到 mysql 整體的頁合并和頁分離的情況。

一般來說merge_threshold 設(shè)置時 50% , 而太小的 merge_threshold 會導(dǎo)致在整體數(shù)據(jù)量不變化的情況下，整體的數(shù)據(jù)占用空間變大，相對的就是內(nèi)存的占用會變大。 

所以監(jiān)控也的merge 和 split  是查看當(dāng)前的 merge_threshold 十分合適以及系統(tǒng)整體的運行情況的一個指標(biāo)（例如這個系統(tǒng)設(shè)計的，都是物理刪，沒有邏輯刪，或經(jīng)常UPDATE 的字段原先小，UPDATE 后都變得很大），這樣的情況

就需要看

index page merge attempts  &  index page merge successful 以及 splits

頻繁的 merge 和 splits 本身就對數(shù)據(jù)庫是一種性能上的影響，并且在操作過程中會影響 DML的相關(guān)操作。

另外借一篇國外文章中關(guān)于主鍵設(shè)計的對于頁分割的影響來看，設(shè)計有缺陷的INNODB 的主鍵表，頁splits 的操作數(shù)要比正常的，多2倍或更多。

通過這個問題，通過這個問題還可以導(dǎo)引出，在MYSQL 中過多的索引并由于表當(dāng)初的設(shè)計的問題，會導(dǎo)致更差的性能問題，所以針對MYSQL 表的設(shè)對比其他的數(shù)據(jù)庫設(shè)計要更嚴(yán)謹(jǐn)。

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“MYSQL中監(jiān)控參數(shù)的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關(guān)注億速云行業(yè)資訊頻道，更多相關(guān)知識等著你來學(xué)習(xí)!