一、事務並發調度的問題
- 臟讀：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。