mysql數(shù)據(jù)庫中的鎖機制

這篇文章將為大家詳細講解有關MySQL數(shù)據(jù)庫中的鎖機制，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

成都創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供巴楚網(wǎng)站建設、巴楚做網(wǎng)站、巴楚網(wǎng)站設計、巴楚網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、巴楚企業(yè)網(wǎng)站模板建站服務，10余年巴楚做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡服務。

Mysql的鎖主要分為3大類：

表級鎖：存儲引擎為Myisam。鎖住整個表，特點是開銷小，加鎖快，鎖定力度大，發(fā)生鎖沖突的概率最高，并發(fā)度最低。

頁級鎖：存儲引擎為BDB。鎖住某一頁的數(shù)據(jù)（16kb左右），特點：開銷和枷鎖時間介于表級和行級之間；會出現(xiàn)死鎖，鎖定力度介于表鎖和行鎖之間，并發(fā)度一般。

行級鎖：存儲引擎為innodb。鎖住某一行的數(shù)據(jù)，特點：鎖的實現(xiàn)更加復雜，開銷大，加鎖速度慢。

根據(jù)以上特點，僅從鎖的角度來說：表級鎖更適合于以查詢?yōu)橹?，只有少量按索引條件更新數(shù)據(jù)的應用，如Web應用；而行級鎖則更適合于有大量按索引條件并發(fā)更新少量不同數(shù)據(jù)，同時又有并發(fā)查詢的應用，如一些在線事務處理（OLTP）系統(tǒng)。

接下來進行行級鎖的詳解，行級鎖主要分為以下7類：共享/排他鎖、意向鎖、記錄鎖、間隙鎖、臨建鎖、插入意向鎖、自增鎖。

共享/排他鎖：

共享鎖：又稱讀鎖，可以允許讀，但不能寫。共享鎖可以與共享鎖一起使用。語句：

select ... lock in share mode

排他鎖：又稱寫鎖，不能允許讀，也不能允許寫，排他鎖不能與其他所一起使用。語句：

select ... for update

在mysql中，update，delete，insert，alter這些寫的操作默認都會加上排他鎖。Select默認不會加任何鎖類型。一旦寫數(shù)據(jù)的任務沒有完成，數(shù)據(jù)是不能被其他任務讀取的，這對并發(fā)操作有較大的影響。

意向鎖：innoDB為了支持多粒度的鎖，即允許行級鎖和表級鎖共存，而引入意向鎖。意向鎖是指未來的某個時刻，事務可能要加共享/排他鎖，先提前聲明一個意向。這樣如果有人嘗試對全表進行修改，就不需要判斷表中的數(shù)據(jù)是否被加鎖了，只需要通過等待意向互斥鎖被釋放就行了。

意向共享鎖（IS）：事務想要在獲得表中某些記錄的共享鎖，需要在表上先加意向共享鎖。

意向互斥鎖（IX）：事務想要在獲得表中某些記錄的互斥鎖，需要在表上先加意向互斥鎖。

意向鎖其實不會阻塞全表掃描之外的任何請求，它們的主要目的是為了表示是否有人請求鎖定表中的某一行數(shù)據(jù)。

記錄鎖（RS）：單個行記錄上的鎖。記錄鎖總是會鎖住索引記錄，如果innoDB存儲引擎表

在建立的時候沒有設置任何一個索引，那么innoDB存儲引擎會使用隱式的主鍵來進行鎖定。

間隙鎖（GR）：間隙鎖鎖住記錄中的間隔，即范圍查詢的記錄。

 Select * From user where id between 1 and 10 for update

這個腳本會鎖住1到10的數(shù)據(jù)，以防止其他事務修改該區(qū)間的記錄；

間隙鎖的主要目的，就是為了防止其他事務在間隔中插入數(shù)據(jù)，以導致“不可重復讀”。如果把事務的隔離級別降級為讀提交(Read Committed, RC)，間隙鎖則會自動失效

臨建鎖（next-key Locks）：臨建鎖是記錄鎖和間隙鎖的組合，鎖的范圍既包含記錄又包含索引區(qū)間。默認情況下，innoDB使用臨建鎖來鎖定記錄。但當查詢的索引含有唯一屬性的時候，臨建鎖會進行優(yōu)化，將其降級為記錄鎖，即僅鎖住索引本身，不是范圍。

臨鍵鎖的主要目的，也是為了避免幻讀(Phantom Read)。如果把事務的隔離級別降級為RC，臨鍵鎖則也會失效。

插入意向鎖(insert intention locks):對已有數(shù)據(jù)行的修改和刪除，必須加互斥鎖，對于數(shù)據(jù)的插入，加插入意向鎖。是專門針對于insert操作的。

自增鎖（auto-inc locks）：是一種特殊的表級別的鎖，專門針對事務插入auto-increment類型的列。最簡單的情況，如果一個事務正在往表中插入記錄，所有其他事務的插入必須等待，以便第一個事務插入的行，是連續(xù)的主鍵值。

接下看講一下其他的鎖：

死鎖：產(chǎn)生是因為線程鎖之間交替等待產(chǎn)生的。值兩個或兩個以上的事務在執(zhí)行過程中，因爭奪資源而造成的一種相互等待的現(xiàn)象。

Mysql處理死鎖的方法：根據(jù)數(shù)據(jù)寫的數(shù)據(jù)量的大小來回滾小事務。

樂觀/悲觀鎖：

樂觀鎖：樂觀的假定大概率不會發(fā)生并發(fā)更新沖突，訪問，處理數(shù)據(jù)的過程中不加鎖，只在更新數(shù)據(jù)時根據(jù)版本號或時間戳判斷是否有沖突，有則處理，無責提交事務。

如果系統(tǒng)并發(fā)量非常大，悲觀鎖會帶來非常大的性能問題，選擇使用樂觀鎖，現(xiàn)在大部分應用屬于樂觀鎖

悲觀鎖:悲觀的假定大概率會發(fā)生并發(fā)更新沖突，訪問，處理數(shù)據(jù)前就加排他鎖，在整個數(shù)據(jù)處理過程中鎖定數(shù)據(jù)，事務提交或回滾后才釋放鎖。

優(yōu)點：

悲觀并發(fā)控制實際上是“先取鎖再訪問”的保守策略，為數(shù)據(jù)處理的安全提供了保證。

缺點：

（a）在效率方面，處理加鎖的機制會讓數(shù)據(jù)庫產(chǎn)生額外的開銷，還有增加產(chǎn)生死鎖的機會；

（b）在只讀型事務處理中由于不會產(chǎn)生沖突，也沒必要使用鎖，這樣做只能增加系統(tǒng)負載；還有會降低了并行性，一個事務如果鎖定了某行數(shù)據(jù)，其他事務就必須等待該事務處理完才可以處理那行數(shù)

建議：

控制事務的大?。ú僮鲗懙臄?shù)據(jù)量）
使用鎖的時候盡量要配合與攜帶索引的字段使用，避免升級為表鎖
范圍查詢，盡量減少基于范圍查詢的事務的大小
如果業(yè)務必須要使用鎖，鎖的沖突特別高的話，改為表鎖
可以根據(jù)項目自身的情況調(diào)節(jié)事務的innodb_flush_log_at_trx_commit

關于mysql數(shù)據(jù)庫中的鎖機制就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。

文章標題：mysql數(shù)據(jù)庫中的鎖機制
分享地址：http://muchs.cn/article8/jpiiop.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供面包屑導航、網(wǎng)站改版、網(wǎng)站建設、網(wǎng)站導航、企業(yè)網(wǎng)站制作、

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容