MySQL 那些監控參數 問 答 （4）REDO AHI latch 鎖
- 2020 年 4 月 10 日
- 筆記
2020已經悄然來到身邊，感覺時間過的很快，學習的過程也是，一陣熱乎的很簡單，難再堅持兩個字好寫，做起來確實是難事。本系列後續還會有，會因為監控這個事情本身就沒有完，只有更加的盡善盡美。所以監控系列還會有更多的內容，但會比較分散。
正文
問： 我的系統裏面有大事務，怎麼辨別其中可能會出現的問題？
在MYSQL中有一個共識點，就是不建議有較複雜的整體性的事務一次性處理，建議是分開處理，降低一個大事務的裏面的關聯性，讓他變成多個事務來處理。當在MYSQL 中出現了超大事務對系統是不好，但如何解釋清楚，這就是一個問題。
1 Checkpoint ,眾所周知如果 dirty page 到達一個值觸發的比率會進行臟頁的刷新，當然checkpoint 本身也有四種模式對應的方式來刷新數據到磁盤。
一個事務完整的一個階段如下
- 創建階段：事務創建一條日誌；
- 日誌刷盤：日誌寫入到磁盤上的日誌文件；
- 數據刷盤：日誌對應的臟頁數據寫入到磁盤上的數據文件；
- 寫CKP：日誌被當作Checkpoint寫入日誌文件；
其中會有幾個點需要注意，
1 日誌空間的 7/8的位置，如果日誌寫到這個位置會開始異步的進行checkpoint ,但不阻塞事務
2 日誌的 15/16的位置，如果觸發到這個點，會停止一些當前事務，開始刷盤
3 達到 31/32 的位置，開始做last checkpoint
4 達到日誌空間的大小，停止一些事務，做last checkpoint
所以就會存在 當大事務一次性寫入的數量較大，並持續性當達到 7/8 和 15/16之間的位置，整體系統就會處於I/O繁忙刷磁盤的情況，當到達15/16 整體系統就不在接受操作了。
所以我們就必須要監控到底日誌佔用的情況,使用下面的方式監控
select count/1000000 from innodb_metrics where name like '%innodb_check%';
查看checkpoint 佔用的整體的百分比。
問：當前數據庫的innodb的log 寫入的情況如何，有么有等待的狀態，存在不存在瓶頸？
這裡指的是redo log 的寫入有沒有瓶頸，我們可以監控 Innodb_os_log_pending_writes 參數是否有增長的泰式，如果持續的增長，則說明以上日誌的寫入有性能瓶頸。 而通過Innodb_os_log_written參數可以獲得相關的日誌寫入的位元組數。來進行判斷當前的日誌寫入整體的情況。
問：當前MYSQL 系統的latch 鎖如何，是否存在瓶頸，怎麼改善？
首先latch 是一個內存鎖，主要的作用是，保護共享資源支持並發，本身這兩個事情就是矛盾的，資源要獨享，還要支持並發，自然就要有鎖來保證。
（註：以上鎖並非直接指數據庫的行鎖，頁鎖，表鎖的概念），相關理論請參考mysql latch 鎖，這裡不展開。
對一下的參數進行定期的記錄並比較，可以獲得系統中在檢查時間段中，是否有存在系統latch 爭用厲害的情況，除了查看當下SQL語句執行的情況，還可以根據其他的情況，來調整mysql instance 的數量，來緩解。
select name,count from INNODB_METRICS where name in ('innodb_rwlock_s_spin_rounds','innodb_rwlock_x_spin_rounds','innodb_rwlock_sx_spin_rounds');
問：自適應哈希索引工作的情況如何？都是MYSQL 自己進行，如何監控？
簡單說一下HASH ,其實這樣的方法也可以自己設計到業務表中，來達到某些目的和加速查詢，MYSQL 這邊提供的自適應HASH 。
對於數據庫的查詢，通過主鍵和索引查詢是常態，MYSQL 的 AHI，針對超過3次以上的對應查詢 = ，>= <= ,in 等操作會進行記錄，並進行數據頁與 自動生成的HASH 值的對應。通過這樣的方式來加速數據的查詢，尤其對於層高已經在 4層的索引，這樣的方法會大大加速數據的查詢。
那怎麼監控AHI 索引的使用情況
select * from INNODB_METRICS where name like 'adaptive_hash_searches'G
