前兩天面試，問到了四種隔離級別，當時覺得大多數數據庫都為read committed，結果沒想到mysql是個例外。在此做一下隔離級別和各種數據庫鎖的使用。
首先說一下ACID四大特性：
四大特性
· 原子性
事務必須是原子工作單元；對於其數據修改，要么全都執行，要么全都不執行。通常，與某個事務關聯的操作具有共同的目標，並且是相互依賴的。如果系統只執行這些操作的一個子集，則可能會破壞事務的總體目標。原子性消除了系統處理操作子集的可能性。
· 一致性
事務在完成時，必須使所有的數據都保持一致狀態。在相關數據庫中，所有規則都必須應用於事務的修改，以保持所有數據的完整性。事務結束時，所有的內部數據結構（如 B 樹索引或雙向鏈表）都必須是正確的。某些維護一致性的責任由應用程序開發人員承擔，他們必須確保應用程序已強制所有已知的完整性約束。例如，當開發用於轉帳的應用程序時，應避免在轉帳過程中任意移動小數點。
· 隔離性
由並發事務所作的修改必須與任何其它並發事務所作的修改隔離。事務查看數據時數據所處的狀態，要么是另一並發事務修改它之前的狀態，要么是另一事務修改它之后的狀態，事務不會查看中間狀態的數據。這稱為可串行性，因為它能夠重新裝載起始數據，並且重播一系列事務，以使數據結束時的狀態與原始事務執行的狀態相同。當事務可序列化時將獲得最高的隔離級別。在此級別上，從一組可並行執行的事務獲得的結果與通過連續運行每個事務所獲得的結果相同。由於高度隔離會限制可並行執行的事務數，所以一些應用程序降低隔離級別以換取更大的吞吐量。
· 持久性
事務完成之后，它對於系統的影響是永久性的。該修改即使出現致命的系統故障也將一直保持。
主要說說這個描述很抽象一致性，舉個例子：A向B轉賬，假設轉賬之前這兩個用戶的錢加起來總共是2000，那么A向B轉賬之后，不管這兩個賬戶怎么轉，A用戶的錢和B用戶的錢加起來的總額還是2000，這個就是事務的一致性。
四種隔離級別
Read Uncommitted（讀取未提交內容）
在該隔離級別，所有事務都可以看到其他未提交事務的執行結果。本隔離級別很少用於實際應用，因為它的性能也不比其他級別好多少。讀取未提交的數據，也被稱之為臟讀（Dirty Read）。
Read Committed（讀取提交內容）
這是大多數數據庫系統的默認隔離級別（但不是MySQL默認的）。它滿足了隔離的簡單定義：一個事務只能看見已經提交事務所做的改變。這種隔離級別 也支持所謂的不可重復讀（Nonrepeatable Read），因為同一事務的其他實例在該實例處理其間可能會有新的commit，所以同一select可能返回不同結果。
Repeatable Read（可重讀）
這是MySQL的默認事務隔離級別，它確保同一事務的多個實例在並發讀取數據時，會看到同樣的數據行。不過理論上，這會導致另一個棘手的問題：幻讀 （Phantom Read）。簡單的說，幻讀指當用戶讀取某一范圍的數據行時，另一個事務又在該范圍內插入了新行，當用戶再讀取該范圍的數據行時，會發現有新的“幻影” 行。InnoDB和Falcon存儲引擎通過多版本並發控制（MVCC，Multiversion Concurrency Control）機制解決了該問題。
Serializable（可串行化）
這是最高的隔離級別，它通過強制事務排序，使之不可能相互沖突，從而解決幻讀問題。簡言之，它是在每個讀的數據行上加上共享鎖。在這個級別，可能導致大量的超時現象和鎖競爭。
這四種隔離級別采取不同的鎖類型來實現，若讀取的是同一個數據的話，就容易發生問題。例如：
臟讀(Drity Read)：某個事務已更新一份數據，另一個事務在此時讀取了同一份數據，由於某些原因，前一個RollBack了操作，則后一個事務所讀取的數據就會是不正確的。
不可重復讀(Non-repeatable read):在一個事務的兩次查詢之中數據不一致，這可能是兩次查詢過程中間插入了一個事務更新的原有的數據。
幻讀(Phantom Read):在一個事務的兩次查詢中數據筆數不一致，例如有一個事務查詢了幾列(Row)數據，而另一個事務卻在此時插入了新的幾列數據，先前的事務在接下來的查詢中，就會發現有幾列數據是它先前所沒有的。
在MySQL中，實現了這四種隔離級別，分別有可能產生問題如下所示：
然后是關於數據庫的各種鎖的總結：
1.共享鎖（又稱讀鎖）、排它鎖（又稱寫鎖）：
InnoDB引擎的鎖機制：InnoDB支持事務，支持行鎖和表鎖用的比較多，Myisam不支持事務，只支持表鎖。
共享鎖（S）：允許一個事務去讀一行，阻止其他事務獲得相同數據集的排他鎖。
排他鎖（X)：允許獲得排他鎖的事務更新數據，阻止其他事務取得相同數據集的共享讀鎖和排他寫鎖。
意向共享鎖（IS）：事務打算給數據行加行共享鎖，事務在給一個數據行加共享鎖前必須先取得該表的IS鎖。
意向排他鎖（IX）：事務打算給數據行加行排他鎖，事務在給一個數據行加排他鎖前必須先取得該表的IX鎖。
說明：
1）共享鎖和排他鎖都是行鎖，意向鎖都是表鎖，應用中我們只會使用到共享鎖和排他鎖，意向鎖是mysql內部使用的，不需要用戶干預。
2）對於UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及數據集加排他鎖（X)；對於普通SELECT語句，InnoDB不會加任何鎖，事務可以通過以下語句顯示給記錄集加共享鎖或排他鎖。
共享鎖（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。
排他鎖（X)：SELECT * FROM table_name WHERE ... FOR UPDATE。
**對於鎖定行記錄后需要進行更新操作的應用，應該使用Select...For update 方式，獲取排它鎖。（用共享鎖，在讀了之后再寫會阻塞，會導致死鎖）
這里說說Myisam：MyISAM在執行查詢語句(SELECT)前，會自動給涉及的所有表加讀鎖，在執行更新操作(UPDATE、DELETE、INSERT等)前，會自動給涉及的表加寫鎖。
3）InnoDB行鎖是通過給索引上的索引項加鎖來實現的，因此InnoDB這種行鎖實現特點意味着：只有通過索引條件檢索數據，InnoDB才使用行級鎖，否則，InnoDB將使用表鎖！
2.樂觀鎖、悲觀鎖：
悲觀鎖：悲觀鎖，正如其名，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度，因此，在整個數據處理過程中，將數據處於鎖定狀態。悲觀鎖的實現，往往依靠數據庫提供的鎖機制（也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改數據）
1）使用悲觀鎖，我們必須關閉mysql數據庫的自動提交屬性，采用手動提交事務的方式，因為MySQL默認使用autocommit模式，也就是說，當你執行一個更新操作后，MySQL會立刻將結果進行提交。
2）需要注意的是，在事務中，只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一筆數據時會等待其它事務結束后才執行，一般SELECT ... 則不受此影響。對於UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及數據集加排他鎖（X)。
3）補充：MySQL select…for update的Row Lock與Table Lock
使用select…for update會把數據給鎖住，不過我們需要注意一些鎖的級別，MySQL InnoDB默認Row-Level Lock，所以只有「明確」地指定主鍵（或有索引的地方），MySQL 才會執行Row lock (只鎖住被選取的數據) ，否則MySQL 將會執行Table Lock (將整個數據表單給鎖住)。
樂觀鎖：
樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖假設認為數據一般情況下不會造成沖突，所以在數據進行提交更新的時候，才會正式對數據的沖突與否進行檢測，如果發現沖突了，則讓返回用戶錯誤的信息，讓用戶決定如何去做（一般是回滾事務）。那么我們如何實現樂觀鎖呢，一般來說有以下2種方式：
1）.使用數據版本（Version）記錄機制實現，這是樂觀鎖最常用的一種實現方式。何謂數據版本？即為數據增加一個版本標識，一般是通過為數據庫表增加一個數字類型的 “version” 字段來實現。當讀取數據時，將version字段的值一同讀出，數據每更新一次，對此version值加一。當我們提交更新的時候，判斷數據庫表對應記錄的當前版本信息與第一次取出來的version值進行比對，如果數據庫表當前版本號與第一次取出來的version值相等，則予以更新，否則認為是過期數據。
2）.樂觀鎖定的第二種實現方式和第一種差不多，同樣是在需要樂觀鎖控制的table中增加一個字段，名稱無所謂，字段類型使用時間戳（timestamp）, 和上面的version類似，也是在更新提交的時候檢查當前數據庫中數據的時間戳和自己更新前取到的時間戳進行對比，如果一致則OK，否則就是版本沖突。
總結：兩種鎖各有優缺點，不可認為一種好於另一種，像樂觀鎖適用於寫比較少的情況下，即沖突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果經常產生沖突，上層應用會不斷的進行retry，這樣反倒是降低了性能，所以這種情況下用悲觀鎖就比較合適。
另外，高並發情況下個人認為樂觀鎖要好於悲觀鎖，因為悲觀鎖的機制使得各個線程等待時間過長，極其影響效率，樂觀鎖可以在一定程度上提高並發度。
3.表鎖、行鎖
表級鎖(table-level locking)：MyISAM和MEMORY存儲引擎
行級鎖(row-level locking) ：InnoDB存儲引擎
頁面鎖(page-level-locking)：BDB存儲引擎
表級鎖：開銷小，加鎖快;不會出現死鎖;鎖定粒度大，發生鎖沖突的概率最高,並發度最低。
行級鎖：開銷大，加鎖慢;會出現死鎖;鎖定粒度最小，發生鎖沖突的概率最低,並發度也最高。
頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間;會出現死鎖;鎖定粒度界於表鎖和行鎖之間，並發度一般。
之后看到了其他的知識，會繼續補充。