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

正文

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

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

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

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

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

• 日志刷盤：日志寫入到磁盤上的日志文件；

• 數(shù)據(jù)刷盤：日志對應(yīng)的臟頁數(shù)據(jù)寫入到磁盤上的數(shù)據(jù)文件；

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

其中會有幾個點需要注意，?

1 日志空間的 7/8的位置，如果日志寫到這個位置會開始異步的進行checkpoint ,但不阻塞事務(wù)

2? 日志的 15/16的位置，如果觸發(fā)到這個點，會停止一些當(dāng)前事務(wù)，開始刷盤

3? 達到 31/32 的位置，開始做last checkpoint?

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

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

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

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

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

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

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

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

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

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

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

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

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

簡單說一下HASH ,其實這樣的方法也可以自己設(shè)計到業(yè)務(wù)表中，來達到某些目的和加速查詢，MYSQL 這邊提供的自適應(yīng)HASH 。

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

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

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

總結(jié)

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

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