快捷導(dǎo)航

MySQL的鎖機(jī)制及排查鎖問題解析

更新時(shí)間：2025年01月03日 14:19:36 作者：快樂江小魚

MySQL的鎖機(jī)制包括行鎖和表鎖,行鎖進(jìn)一步細(xì)分為RecordLock、GapLock和Next-keyLock,行鎖因其細(xì)粒度而減少?zèng)_突但開銷大,可能引起死鎖,本文介紹MySQL的鎖機(jī)制及排查鎖問題,感興趣的朋友一起看看吧

MySQL的鎖機(jī)制及排查鎖問題

按照鎖的粒度可以分為行鎖和表鎖，按照是否可寫可以分為讀鎖和寫鎖。
行鎖是MySQL中粒度最細(xì)的鎖，對當(dāng)前操作的行進(jìn)行加鎖。行鎖會大大減少數(shù)據(jù)庫操作的沖突，加鎖的粒度最小，但是加鎖的開銷最大，有可能會出現(xiàn)死鎖。
行鎖的實(shí)現(xiàn)算法有Record Lock記錄鎖、Gap Lock間隙鎖和Next-key Lock。記錄鎖是對單行記錄加鎖，對索引項(xiàng)加鎖，鎖定符合條件的行，其他事務(wù)不能修改和刪除加鎖項(xiàng)。間隙鎖鎖定的是一個(gè)范圍，不包含記錄本身。對索引項(xiàng)之間的間隙加鎖，鎖定記錄的范圍，對第一條記錄前的間隙或最后一條記錄后的間隙加鎖，不包含索引項(xiàng)本身。其他事務(wù)不能在鎖范圍內(nèi)插入數(shù)據(jù)，這樣可以防止其他事務(wù)新增幻影行。Next-key Lock是默認(rèn)的鎖，同時(shí)鎖住數(shù)據(jù)和間隙鎖。鎖定索引項(xiàng)本身和索引范圍。
表鎖是MySQL中粒度最大的鎖，對當(dāng)前正在操作的整張表加鎖，資源開銷比行鎖少，不會出現(xiàn)死鎖的情況，但是發(fā)生鎖沖突的概率比較大。InnoDB默認(rèn)的是行鎖。
讀鎖也成為共享鎖，其他用戶可以并發(fā)讀取數(shù)據(jù)，但任何事務(wù)都不能獲取數(shù)據(jù)上的寫鎖，直到釋放所有的讀鎖。
寫鎖也成為排他鎖，如果事務(wù)T對數(shù)據(jù)對象A加上寫鎖，就只允許事務(wù)T讀取和修改數(shù)據(jù)對象A。

排查鎖的問題

排查鎖的問題可以從表鎖和行鎖考慮。
查看表鎖的情況后分析。

-- 查看所有線程
show full processlist;
-- 查看正在使用的表
show open tables;
-- 查看innodb服務(wù)器信息
show engine innodb status;
-- 查看表鎖：Table_locks_waited-出現(xiàn)表鎖爭用而發(fā)生的等待次數(shù)，Table_locks_immediate-可以立即獲取鎖的次數(shù)
show status like 'table%';

查看行鎖的情況

-- Innodb_row_lock_current_waits：當(dāng)前正在等待鎖定的數(shù)量
-- Innodb_row_lock_time：從系統(tǒng)啟動(dòng)到現(xiàn)在鎖定的總時(shí)間
-- Innodb_row_lock_time_avg：每次等待所花的平均時(shí)間
-- Innodb_row_lock_time_max：從系統(tǒng)啟動(dòng)到現(xiàn)在等待最長的一次所花的時(shí)間
-- Innodb_row_lock_waites：從系統(tǒng)啟動(dòng)到現(xiàn)在總共等待的次數(shù)
show status like 'innodb_row_lock%';
-- 查看information_schema庫
-- innodb_trx表用來顯示當(dāng)前運(yùn)行innodb事務(wù)情況，不能判斷鎖的情況
-- innodb_locks表可以查看鎖的情況
-- innodb_lock_waits表可以查看鎖等待的情況

到此這篇關(guān)于MySQL的鎖機(jī)制及排查鎖問題的文章就介紹到這了,更多相關(guān)mysql鎖機(jī)制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: