如何分析MySQL中的REDO AHI latch鎖

這篇文章將為大家詳細講解有關如何分析MySQL中的REDO AHI  latch鎖，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

正文

問：  我的系統里面有大事務，怎么辨別其中可能會出現的問題？

在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

關于如何分析MySQL中的REDO AHI  latch鎖就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。