前幾天一個金融行業的朋友和我討論數據庫選型的事情，他們在選擇分布式數據庫的時候發現這些數據庫支持的事務隔離級別與Oracle有較大差異，有位領導認為對事務隔離級別的支持能力說明了數據庫在并發處理方面的能力，因此要在選型中占有比較高的分值，甚至要在較高事務隔離級別下測試數據庫的并發性能。他對此持不同的看法。
數據庫事務隔離級別的概念最早是在1981年由IBM的Jim Gray等人提出的，他們在論文《The Notions of Consistency and Predicate Locks in a Database System》中定義了四種隔離級別，分別是：
讀未提交(Read uncommitted)：最低的隔離級別，允許一個事務讀取另一個未提交事務的數據，可能導致臟讀、不可重復讀、幻讀等問題。 讀提交(Read committed)：目前被應用最為廣泛的使用的事務隔離級別，只允許一個事務讀取另一個已提交事務的數據，可以避免臟讀，但不能避免不可重復讀、幻讀等問題。 可重復讀(Repeatable read)：較高的隔離級別，保證一個事務在執行過程中對同一數據的多次讀取結果都是一致的，可以避免臟讀、不可重復讀，但不一定能避免幻讀等問題。 串行化(Serializable)：最高的隔離級別，要求事務串行執行，不允許并發訪問和修改同一數據，可以避免臟讀、不可重復讀、幻讀等所有問題，但性能最差。數據庫的多種事務隔離級別是想為應用開發者提供不同的并發控制，從而適應各種不同的應用應用場景。這在T/S架構流行的80/90年代應用廣泛。那時候所有的計算都只能在主機或者小型機上完成，因此數據庫提供的這個功能可以大大簡化應用開發。C/S架構出現后，特別是后來的三層架構大行其道的時代之后，Read Committed變成了最為常用的事務隔離級別，其他事務隔離級別大多數都基本上不用了。比Read Committed更高的事務隔離級別被前置到應用前端或者中間層來實現了。
更高的事務隔離級別的最著名的例子就是分頁查詢，在RC隔離級別下，哪怕是在一個事務中，我們在前端分頁查詢同一個數據時，都會看到“臟數據”，因為這些數據在我們讀的時候也會有人同時在修改和寫入新的滿足條件的數據。對于這種方式的處理方法一般來說就是容忍“臟數據”，互聯網應用一般都是這樣處理的。而對于數據一致性要求很高的財務系統，則一般采用在中間層緩存數據或者使用全局臨時表緩存數據的方式來確保數據的一致性。
現在的應用較少的通過事務隔離級別來處理這種高一致性要求的數據的主要原因還是因為技術發展了，多層架構讓中間層有了更為強大的可擴展的處理能力，而數據庫本身也因為硬件的發展能夠承受大量的臨時表存儲數據的需求。這些應用層實現的更高事務隔離級別的應用需求往往比通過數據庫實現有更高的靈活性，因此比RC更高的事務隔離級別實際上在我們的大多數應用中已經早就沒有人使用了。
可能有朋友要問，為什么MySQL的默認事務隔離級別不是RC而是RR呢?這和MySQL數據庫的歷史有關，MySQL數據庫因為早期的BINLOG復制不支持RAW格式的問題而必須選擇RR，如果使用RC無法確保復制數據的一致性。但是用了RR這種事務隔離級別，又會引起數據庫的并發性能受到影響，因此MySQL引入了GAP LOCK這種特殊的鎖機制，來降低RR對數據庫并發的性能影響。哪怕是引入了GAP LOCK，在RR隔離級別下，對于SELECT … FOR UPDATE的操作，RR隔離級別也會比RC有更多的鎖阻塞，因此我們建議MySQL用戶如果BINLOG復制使用能夠RAW的情況下，還是把默認的事務隔離級別設置為RC。
回到文章頭上的那個金融交易系統的例子，這個例子是十分典型的RC事務隔離級別就是最 佳隔離級別的例子，在此種應用場景下，還把事務隔離級別看作是數據庫選型的重要因素，就有點不太合適了。
分布式數據庫最早的初衷就是提高并發交易的能力，因此它們在較高事務隔離級別方面天然就處于劣勢的，用這種因素去選型，肯定就與選型的初衷背道而馳了。實際上與前面所說的一樣，目前我們的應用開發大多數都基于RC事務隔離級別。更高的事務隔離級別的應用需求大多數都在應用中去處理了，或者說哪怕要用數據庫來實現，這種應用場景應該也不會是有很高并發的。因此在較高事務隔離級別下測試并發性能對于大多數用戶來說確實是沒有太大必要了。
