一、事務并發調度的問題

臟讀：A事務讀取B事務尚未提交的更改數據，并在這個數據基礎上操作。如果B事務回滾，那么A事務讀到的數據根本不是合法的，稱為臟讀。在oracle中，由于有version控制，不會出現臟讀。

不可重復讀：A事務讀取了B事務已經提交的更改（或刪除）數據。比如A事務第一次讀取數據，然后B事務更改該數據并提交，A事務再次讀取數據，兩次讀取的數據不一樣。

幻讀：A事務讀取了B事務已經提交的新增數據。注意和不可重復讀的區別，這里是新增，不可重復讀是更改（或刪除）。這兩種情況對策是不一樣的，對于不可重復讀，只需要采取行級鎖防止該記錄數據被更改或刪除，然而對于幻讀必須加表級鎖，防止在這個表中新增一條數據。

第一類丟失更新：A事務撤銷時，把已提交的B事務的數據覆蓋掉。

第二類丟失更新：A事務提交時，把已提交的B事務的數據覆蓋掉。

三級封鎖協議

一級封鎖協議：事務T中如果對數據R有寫操作，必須在這個事務中對R的第一次讀操作前對它加X鎖，直到事務結束才釋放。事務結束包括正常結束（COMMIT）和非正常結束（ROLLBACK）。

二級封鎖協議：一級封鎖協議加上事務T在讀取數據R之前必須先對其加S鎖，讀完后方可釋放S鎖。?

三級封鎖協議?：一級封鎖協議加上事務T在讀取數據R之前必須先對其加S鎖，直到事務結束才釋放。

可見，三級鎖操作一個比一個厲害（滿足高級鎖則一定滿足低級鎖）。但有個非常致命的地方，一級鎖協議就要在第一次讀加x鎖，直到事務結束。幾乎就要在整個事務加寫鎖了，效率非常低。三級封鎖協議只是一個理論上的東西，實際數據庫常用另一套方法來解決事務并發問題。 二、隔離性級別 mysql用意向鎖（另一種機制）來解決事務并發問題，為了區別封鎖協議，弄了一個新概念隔離性級別：包括Read Uncommitted、Read Committed、Repeatable Read、Serializable。mysql 一般默認Repeatable Read。 總結一下，repeatable read能解決臟讀和不可重復讀，但不能解決丟失修改。 三、mysql的行鎖和表鎖 下面對行鎖和表鎖進行一個簡單的介紹。

• 表級鎖：每次操作鎖住整張表。開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高，并發度最低；
• 行級鎖：每次操作鎖住一行數據。開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低，并發度也最高；
• 頁面鎖：開銷和加鎖時間界于表鎖和行鎖之間；會出現死鎖；鎖定粒度界于表鎖和行鎖之間，并發度一般。

1、MyISAM的鎖 稍微提一下MyISAM，只說和InnoDB不同的。 a. MyISAM只有表鎖，鎖又分為讀鎖和寫鎖。　 b.?沒有事務，不用考慮并發問題 c.?由于鎖的粒度太大，所以當該表寫并發量較高時，要等待的查詢就會很多了。 2、InnoDB的行鎖和表鎖 沒有特定的語法。mysql的行鎖是通過索引體現的。 如果where條件中只用到索引項，則加的是行鎖；否則加的是表鎖。比如說主鍵索引，唯一索引和聚簇索引等。如果sql的where是全表掃描的，想加行鎖也愛莫能助。 行鎖和表鎖對我們編程的影響是要在where中盡量只用索引項，否則就會觸發表鎖。 3、加鎖和解鎖 在InnoDB中，select,insert,update,delete等語句執行時都會自動加解鎖。select的鎖一般執行完就釋放了，修改操作的X鎖會持有到事務結束，效率高很多。 mysql也給用戶提供了加鎖的機會，只要在sql后加LOCK IN SHARE MODE 或FOR UPDATE 共享鎖（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE 排他鎖（X）：SELECT * FROM table_name WHERE ... FOR UPDATE 值得注意的是，自己加的鎖沒有釋放鎖的語句，所以鎖會持有到事務結束。 四、解決丟失修改--樂觀鎖和悲觀鎖 加鎖就是為了解決丟失修改。如果一個事務中只有一句sql，數據庫是可以保證它是并發安全的。丟失修改的特征就是在一個事務中先讀P數據，再寫P數據。所謂丟失修改，一般是A事務有兩個操作，后一個操作依賴于前一個操作，之后后一個操作覆蓋了B事務的寫操作。 如果一個事務先讀后寫同一份數據，就可能發生丟失修改，要做一些處理。下面對樂觀鎖和悲觀鎖進行一個簡單的介紹。 悲觀鎖和樂觀鎖的概念： 悲觀鎖（Pessimistic Concurrency Control，PCC）：假定會發生并發沖突，屏蔽一切可能違反數據完整性的操作。 樂觀鎖（Optimistic Concurrency Control，OCC）：假設不會發生并發沖突，只在提交操作時檢查是否違反數據完整性。 樂觀鎖和悲觀鎖也不僅僅能用在數據庫中，也能用在線程中。 悲觀鎖的缺陷是不論是頁鎖還是行鎖，加鎖的時間可能會很長，這樣可能會長時間的限制其他用戶的訪問，也就是說悲觀鎖的并發訪問性不好。 樂觀鎖不能解決臟讀，加鎖的時間要比悲觀鎖短（只是在執行sql時加了基本的鎖保證隔離性級別），樂觀鎖可以用較大的鎖粒度獲得較好的并發訪問性能。但是如果第二個用戶恰好在第一個用戶提交更改之前讀取了該對象，那么當他完成了自己的更改進行提交時，數據庫就會發現該對象已經變化了，這樣，第二個用戶不得不重新讀取該對象并作出更改。 可見，樂觀鎖更適合解決沖突概率極小的情況；而悲觀鎖則適合解決并發競爭激烈的情況，盡量用行鎖，縮小加鎖粒度，以提高并發處理能力，即便加行鎖的時間比加表鎖的要長。 悲觀鎖的例子 這里僅僅提供一種解決丟失修改的悲觀鎖例子。丟失修改的特征就是在一個事務中先讀P數據，再寫P數據。而且一級鎖協議能解決丟失修改，所以如果事務A 中寫P，我們只要在A中第一次讀P前加X鎖。 樂觀鎖的例子 樂觀鎖檢測并發沖突的常見的兩種做法：

使用數據版本（Version）。在P數據上（通常每一行）加version字段(int)，A事務在讀數據P 時同時讀出版本號，在修改數據前檢測最新版本號是否等于先前取出的版本號，如果是，則修改，同時把版本號+1；否則要么回滾，要么重新執行事務。另外，數據P的所有修改操作都要把版本號+1。有一個非常重要的點，版本號是用來查看被讀的變量有無變化，而不是針對被寫的變量，作用是防止被依賴的變量有修改。

使用時間戳(TimeStamp)。做法類似于1中。

總結 樂觀鎖更適合并發競爭少的情況，最好隔那么3-5分鐘才有一次沖突。當并發量為10時就能明顯感覺樂觀鎖更慢； 上面只是一讀一寫。考慮如果一個事務中有3個寫，如果每次寫都是九死一生，事務提交比較難，這時就更要考慮是不是要用樂觀鎖了。 但是，當分布式數據庫規模大到一定程度后，又另說了。基于悲觀鎖的分布式鎖在集群大到一定程度后（從幾百臺擴展到幾千臺時），性能開銷就打得無法接受。所以目前的趨勢是大規模的分布式數據庫更傾向于用樂觀鎖來達成external consistency。

轉載于:https://www.cnblogs.com/Demrystv/p/9109325.html

總結

以上是生活随笔為你收集整理的数据库中的行锁和表锁的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。