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

10年的靈璧網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。成都營(yíng)銷網(wǎng)站建設(shè)的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整靈璧建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)建站從事“靈璧網(wǎng)站設(shè)計(jì)”,“靈璧網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

正文

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對(duì)一下的參數(shù)進(jìn)行定期的記錄并比較，可以獲得系統(tǒng)中在檢查時(shí)間段中，是否有存在系統(tǒng)latch 爭(zhēng)用厲害的情況，除了查看當(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 自己進(jìn)行，如何監(jiān)控？

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

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

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

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

關(guān)于如何分析MySQL中的REDO AHI  latch鎖就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。