2020已經(jīng)悄然來(lái)到身邊，感覺(jué)時(shí)間過(guò)的很快，學(xué)習(xí)的過(guò)程也是，一陣熱乎的很簡(jiǎn)單，難再堅(jiān)持兩個(gè)字好寫(xiě)，做起來(lái)確實(shí)是難事。本系列后續(xù)還會(huì)有，會(huì)因?yàn)楸O(jiān)控這個(gè)事情本身就沒(méi)有完，只有更加的盡善盡美。所以監(jiān)控系列還會(huì)有更多的內(nèi)容，但會(huì)比較分散。

正文

問(wèn)：? 我的系統(tǒng)里面有大事務(wù)，怎么辨別其中可能會(huì)出現(xiàn)的問(wèn)題？

在MYSQL中有一個(gè)共識(shí)點(diǎn)，就是不建議有較復(fù)雜的整體性的事務(wù)一次性處理，建議是分開(kāi)處理，降低一個(gè)大事務(wù)的里面的關(guān)聯(lián)性，讓他變成多個(gè)事務(wù)來(lái)處理。當(dāng)在MYSQL 中出現(xiàn)了超大事務(wù)對(duì)系統(tǒng)是不好，但如何解釋清楚，這就是一個(gè)問(wèn)題。

1 Checkpoint ,眾所周知如果 dirty page 到達(dá)一個(gè)值觸發(fā)的比率會(huì)進(jìn)行臟頁(yè)的刷新，當(dāng)然checkpoint 本身也有四種模式對(duì)應(yīng)的方式來(lái)刷新數(shù)據(jù)到磁盤(pán)。

一個(gè)事務(wù)完整的一個(gè)階段如下

• 創(chuàng)建階段：事務(wù)創(chuàng)建一條日志；

• 日志刷盤(pán)：日志寫(xiě)入到磁盤(pán)上的日志文件；

• 數(shù)據(jù)刷盤(pán)：日志對(duì)應(yīng)的臟頁(yè)數(shù)據(jù)寫(xiě)入到磁盤(pán)上的數(shù)據(jù)文件；

• 寫(xiě)CKP：日志被當(dāng)作Checkpoint寫(xiě)入日志文件；

其中會(huì)有幾個(gè)點(diǎn)需要注意，?

1 日志空間的 7/8的位置，如果日志寫(xiě)到這個(gè)位置會(huì)開(kāi)始異步的進(jìn)行checkpoint ,但不阻塞事務(wù)

2? 日志的 15/16的位置，如果觸發(fā)到這個(gè)點(diǎn)，會(huì)停止一些當(dāng)前事務(wù)，開(kāi)始刷盤(pán)

3? 達(dá)到 31/32 的位置，開(kāi)始做last checkpoint?

4? 達(dá)到日志空間的大小，停止一些事務(wù)，做last checkpoint

所以就會(huì)存在 當(dāng)大事務(wù)一次性寫(xiě)入的數(shù)量較大，并持續(xù)性當(dāng)達(dá)到 7/8 和 15/16之間的位置，整體系統(tǒng)就會(huì)處于I/O繁忙刷磁盤(pán)的情況，當(dāng)?shù)竭_(dá)15/16 整體系統(tǒng)就不在接受操作了。

所以我們就必須要監(jiān)控到底日志占用的情況,使用下面的方式監(jiān)控

select count/1000000 from innodb_metrics where name like '%innodb_check%';

查看checkpoint 占用的整體的百分比。

問(wèn)：當(dāng)前數(shù)據(jù)庫(kù)的innodb的log 寫(xiě)入的情況如何，有么有等待的狀態(tài)，存在不存在瓶頸？

這里指的是redo log 的寫(xiě)入有沒(méi)有瓶頸，我們可以監(jiān)控 Innodb_os_log_pending_writes 參數(shù)是否有增長(zhǎng)的泰式，如果持續(xù)的增長(zhǎng)，則說(shuō)明以上日志的寫(xiě)入有性能瓶頸。?而通過(guò)Innodb_os_log_written參數(shù)可以獲得相關(guān)的日志寫(xiě)入的字節(jié)數(shù)。來(lái)進(jìn)行判斷當(dāng)前的日志寫(xiě)入整體的情況。

問(wèn)：當(dāng)前MYSQL 系統(tǒng)的latch 鎖如何，是否存在瓶頸，怎么改善？

首先latch 是一個(gè)內(nèi)存鎖，主要的作用是，保護(hù)共享資源支持并發(fā)，本身這兩個(gè)事情就是矛盾的，資源要獨(dú)享，還要支持并發(fā)，自然就要有鎖來(lái)保證。

（注：以上鎖并非直接指數(shù)據(jù)庫(kù)的行鎖，頁(yè)鎖，表鎖的概念），相關(guān)理論請(qǐng)參考mysql latch 鎖，這里不展開(kāi)。

對(duì)一下的參數(shù)進(jìn)行定期的記錄并比較，可以獲得系統(tǒng)中在檢查時(shí)間段中，是否有存在系統(tǒng)latch 爭(zhēng)用厲害的情況，除了查看當(dāng)下SQL語(yǔ)句執(zhí)行的情況，還可以根據(jù)其他的情況，來(lái)調(diào)整mysql instance 的數(shù)量，來(lái)緩解。

select name,count from INNODB_METRICS where name in ('innodb_rwlock_s_spin_rounds','innodb_rwlock_x_spin_rounds','innodb_rwlock_sx_spin_rounds');

問(wèn)：自適應(yīng)哈希索引工作的情況如何？都是MYSQL 自己進(jìn)行，如何監(jiān)控？

簡(jiǎn)單說(shuō)一下HASH ,其實(shí)這樣的方法也可以自己設(shè)計(jì)到業(yè)務(wù)表中，來(lái)達(dá)到某些目的和加速查詢(xún)，MYSQL 這邊提供的自適應(yīng)HASH 。

對(duì)于數(shù)據(jù)庫(kù)的查詢(xún)，通過(guò)主鍵和索引查詢(xún)是常態(tài)，MYSQL 的 AHI，針對(duì)超過(guò)3次以上的對(duì)應(yīng)查詢(xún) = ，>=? ?<=? ,in 等操作會(huì)進(jìn)行記錄，并進(jìn)行數(shù)據(jù)頁(yè)與 自動(dòng)生成的HASH 值的對(duì)應(yīng)。通過(guò)這樣的方式來(lái)加速數(shù)據(jù)的查詢(xún)，尤其對(duì)于層高已經(jīng)在 4層的索引，這樣的方法會(huì)大大加速數(shù)據(jù)的查詢(xún)。

那怎么監(jiān)控AHI 索引的使用情況

select * from INNODB_METRICS where name like 'adaptive_hash_searches'\G

總結(jié)

以上是生活随笔為你收集整理的MySQL 那些监控参数 问 答 （4）REDO AHI latch 锁的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。