36、談談MySQL支援的事務隔離級別，以及悲觀鎖和樂觀鎖的原理和應用場景？
目錄
今天我要問你的問題是，談談 MySQL 支援的事務隔離級別，以及悲觀鎖和樂觀鎖的原理和應用場景？
在日常開發中，尤其是業務開發，少不了利用 Java 對資料庫進行基本的增刪改查等資料操作，這也是 Java 工程師的必備技能之一。做好資料操作，不僅僅需要對 Java 語言相關框架的掌握，更需要對各種資料庫自身體系結構的理解。今天這一講，作為補充 Java 面試考察知識點的完整性，關於資料庫的應用和細節還需要在實踐中深入學習。
今天我要問你的問題是，談談 MySQL 支援的事務隔離級別，以及悲觀鎖和樂觀鎖的原理和應用場景？
典型回答
所謂隔離級別（Isolation Level），就是在資料庫事務中，為保證併發資料讀寫的正確性而提出的定義，它並不是 MySQL 專有的概念，而是源於ANSI/ISO制定的SQL-92標準。
每種關係型資料庫都提供了各自特色的隔離級別實現，雖然在通常的定義中是以鎖為實現單元，但實際的實現千差萬別。以最常見的 MySQL InnoDB 引擎為例，它是基於 MVCC（Multi-Versioning Concurrency Control）和鎖的複合實現，按照隔離程度從低到高，MySQL 事務隔離級別分為四個不同層次：
- 讀未提交（Read uncommitted），就是一個事務能夠看到其他事務尚未提交的修改，這是最低的隔離水平，允許髒讀出現。
- 讀已提交（Read committed），事務能夠看到的資料都是其他事務已經提交的修改，也就是保證不會看到任何中間性狀態，當然髒讀也不會出現。讀已提交仍然是比較低級別的隔離，並不保證再次讀取時能夠獲取同樣的資料，也就是允許其他事務併發修改資料，允許不可重複讀和幻象讀（Phantom: Read）出現。
- 可重複讀（Repeatable reads），保證同一個事務中多次讀取的資料是一致的，這是 MySQL InnoDB 引擎的預設隔離級別，但是和一些其他資料庫實現不同的是，可以簡單認為 MySQL 在可重複讀級別不會出現幻象讀。
- 序列化（Serializable），併發事務之間是序列化的，通常意味著讀取需要獲取共享讀鎖，更新需要獲取排他寫鎖，如果 SQL 使用 WHERE 語句，還會獲取區間鎖（MySQL 以 GAP 鎖形式實現，可重複讀級別中預設也會使用），這是最高的隔離級別。
至於悲觀鎖和樂觀鎖，也並不是 MySQL 或者資料庫中獨有的概念，而是併發程式設計的基本概念。主要區別在於，操作共享資料時，“悲觀鎖”即認為資料出現衝突的可能性更大，而“樂觀鎖”則是認為大部分情況不會出現衝突，進而決定是否採取排他性措施。
反映到 MySQL 資料庫應用開發中，悲觀鎖一般就是利用類似 SELECT … FOR UPDATE 這樣的語句，對資料加鎖，避免其他事務意外修改資料。樂觀鎖則與 Java 併發包中的 AtomicFieldUpdater 類似，也是利用 CAS 機制，並不會對資料加鎖，而是通過對比資料的時間戳或者版本號，來實現樂觀鎖需要的版本判斷。
我認為前面提到的 MVCC，其本質就可以看作是種樂觀鎖機制，而排他性的讀寫鎖、雙階段鎖等則是悲觀鎖的實現。
有關它們的應用場景，你可以構建一下簡化的火車餘票查詢和購票系統。同時查詢的人可能很多，雖然具體座位票只能是賣給一個人，但餘票可能很多，而且也並不能預測哪個查詢者會購票，這個時候就更適合用樂觀鎖。
考點分析
今天的問題來源於實際面試，這兩部分問題反映了面試官試圖考察面試者在日常應用開發中，是否學習或者思考過資料庫內部的機制，是否瞭解併發相關的基礎概念和實踐。
我從普通資料庫應用開發者的角度，提供了一個相對簡化的答案，面試官很有可能進一步從例項的角度展開，例如設計一個典型場景重現髒讀、幻象讀，或者從資料庫設計的角度，可以用哪些手段避免類似情況。我建議你在準備面試時，可以在典型的資料庫上試驗一下，驗證自己的觀點。
其他可以考察的點也有很多，在準備這個問題時你也可以對比 Java
語言的併發機制，進行深入理解，例如，隨著隔離級別從低到高，競爭性（Contention）逐漸增強，隨之而來的代價同樣是效能和擴充套件性的下降。
資料庫衍生出很多不同的職責方向：
- 資料庫管理員（DBA），這是一個單獨的專業領域。
- 資料庫應用工程師，很多業務開發者就是這種定位，綜合利用資料庫和其他程式語言等技能，開發業務應用。
- 資料庫工程師，更加側重於開發資料庫、資料庫中介軟體等基礎軟體。
後面兩者與 Java 開發更加相關，但是需要的知識和技能是不同的，所以面試的考察角度也有區別，今天我會分析下對相關知識學習和準備面試的看法。
另外，在資料庫相關領域，Java 工程師最常接觸到的就是 O/R Mapping 框架或者類似的資料庫互動類庫，我會選取最廣泛使用的框架進行對比和分析。
知識擴充套件
首先，我來談談對資料庫相關領域學習的看法，從最廣泛的應用開發者角度，至少需要掌握：
- 資料庫設計基礎，包括資料庫設計中的幾個基本正規化，各種資料庫的基礎概念，例如表、檢視、索引、外來鍵、序列號生成器等，清楚如何將現實中業務實體和其依賴關係對映到資料庫結構中，掌握典型實體資料應該使用什麼樣的資料庫資料型別等。
- 每種資料庫的設計和實現多少會存在差異，所以至少要精通你使用過的資料庫的設計要點。我今天開篇談到的 MySQL 事務隔離級別，就區別於其他資料庫，進一步瞭解 MVCC、Locking 等機制對於處理進階問題非常有幫助；還需要了解，不同索引型別的使用，甚至是底層資料結構和演算法等。
- 常見的 SQL 語句，掌握基礎的 SQL 調優技巧，至少要了解基本思路是怎樣的，例如 SQL 怎樣寫才能更好利用索引、知道如何分析SQL 執行計劃等。
- 更進一步，至少需要了解針對高併發等特定場景中的解決方案，例如讀寫分離、分庫分表，或者如何利用快取機制等，目前的資料儲存也遠不止傳統的關係型資料庫了。
上面的示意圖簡單總結了我對資料庫領域的理解，希望可以給你進行準備時提供個借鑑。當然在準備面試時並不是一味找一堆書悶頭苦讀，我還是建議從實際工作中使用的資料庫出發，側重於結合實踐，完善和深化自己的知識體系。
接下來我們還是回到 Java 本身，目前最為通用的 Java 和資料庫互動技術就是 JDBC，最常見的開源框架基本都是構建在 JDBC 之上，包括我們熟悉的JPA/Hibernate、MyBatis、Spring JDBC Template 等，各自都有獨特的設計特點。
Hibernate 是最負盛名的 O/R Mapping 框架之一，它也是一個 JPA Provider。顧名思義，它是以物件為中心的，其強項更體現在資料庫到 Java 物件的對映，可以很方便地在 Java 物件層面體現外來鍵約束等相對複雜的關係，提供了強大的持久化功能。內部大量使用了Lazy-load等技術提高效率。並且，為了遮蔽資料庫的差異，降低維護開銷，Hibernate加提供了類 SQL 的 HQL，可以自動生成某種資料庫特定的 SQL 語句。
Hibernate 應用非常廣泛，但是過度強調持久化和隔離資料庫底層細節，也導致了很多弊端，例如 HQL 需要額外的學習，未必比深入學習 SQL 語言更高效；減弱程式設計師對 SQL 的直接控制，還可能導致其他代價，本來一句 SQL 的事情，可能被 Hibernate 生成幾條，隱藏的內部細節也阻礙了進一步的優化。
而 MyBatis 雖然仍然提供了一些對映的功能，但更加以 SQL 為中心，開發者可以側重於 SQL 和儲存過程，非常簡單、直接。如果我們的應用需要大量高效能的或者複雜的 SELECT 語句等，“半自動”的 MyBatis 就會比 Hibernate 更加實用。
而 Spring JDBC Template 也是更加接近於 SQL 層面，Spring 本身也可以整合 Hibernate 等 O/R Mapping 框架。
關於這些具體開源框架的學習，我的建議是：
- 從整體上把握主流框架的架構和設計理念，掌握主要流程，例如 SQL 解析生成、SQL 執行到結果對映等處理過程到底發生了什麼。
- 掌握對映等部分的細節定義和原理，根據我在準備專欄時整理的面試題目，發現很多題目都是偏向於對映定義的細節。
- 另外，對比不同框架的設計和實現，既有利於你加深理解，也是面試考察的熱點方向之一。
今天我從資料庫應用開發者的角度，分析了 MySQL 資料庫的部分內部機制，並且補充了我對資料庫相關面試準備和知識學習的建議，最後對主流 O/R Mapping 等框架進行了簡單的對比。
一課一練
關於今天我們討論的題目你做到心中有數了嗎？ 今天的思考題是，從架構設計的角度，可以將 MyBatis 分為哪幾層？每層都有哪些主要模組？