在SQL的標準中事物隔離級別分為以下四種：
1. 讀未提交(Read uncommitted)
2. 讀已提交(Read committed)
3. 可重復讀(Repeatable read)
4. 可串行化(Serializable)
然而PostgreSQL在9.1之前的版本中只是實現(xiàn)了其中兩種，即讀已提交和可串行化，如果在實際應(yīng)用中選擇了另外兩種，那么PostgreSQL將會自動向更嚴格的隔離級別調(diào)整。在PostgreSQL v9.1的版本中提供了三種實現(xiàn)方式，即在原有的基礎(chǔ)上增加了可重復讀。在這篇博客中我們將只是針對2)和4)進行說明和比較，因為在9.1中，3)和4)的差別也是非常小的。
| 讀已提交 | 可串行化 | |
| PostgreSQL缺省隔離級別 | 是 | 否 |
| 其它事物未提交數(shù)據(jù)是否可見 | 不可見 | 不可見 |
| 執(zhí)行效率 | 高 | 低 |
| 適用場景 | 簡單SQL邏輯，如果SQL語句中含有嵌套查詢，那么在多次SQL查詢中將極有可能獲得不同版本的數(shù)據(jù)。 | 復雜SQL邏輯，特別是帶有嵌套的查詢比較適用。 |
| SELECT查詢一致性時間點 | 從該SELECT查詢開始執(zhí)行時，在此查詢執(zhí)行期間，任何其它并發(fā)事物針對該查詢結(jié)果集的數(shù)據(jù)操作都將不會被本次查詢讀到，即本次查詢獲取的數(shù)據(jù)版本是與查詢開始執(zhí)行時的數(shù)據(jù)版本相一致。 | 從該SELECT查詢所在事物開始時，在此查詢執(zhí)行期間，任何其它并發(fā)事物針對該查詢結(jié)果集的數(shù)據(jù)操作都將不會被本次查詢讀到，即本次查詢獲取的數(shù)據(jù)版本是與查詢所在事物開始時的數(shù)據(jù)版本相一致。 |
| 同事物內(nèi)的數(shù)據(jù)操作是否可見 | 比如在同一個事物內(nèi)存在update和select操作，即使當前事物尚未提交，update所作的修改，在當前事物后面的select中依然可見。 | 和讀已提交相同。 |
| 同事物內(nèi)多次相同的select所見的數(shù)據(jù)是否相同 | 不同，由于該級別select的一致性時間點是該查詢開始執(zhí)行時，而多次查詢的時間點將肯定不相同，如果在第一次查詢開始到第二次查詢開始之間，其它的并發(fā)事物修改并提交或當前事物僅修改了查詢將要獲取的數(shù)據(jù)，那么這些數(shù)據(jù)操作的結(jié)果將會在第二個查詢中有所體現(xiàn)。 | 需要分兩步來說，對于同一事物內(nèi)的修改如果發(fā)生在兩次查詢語句之間，那么第二個查詢將會看到這些修改的結(jié)果。然而對于其它并發(fā)事物的修改，將不會造成任何影響，即兩次select的結(jié)果是相同的。原因顯而易見，該隔離級別的select一致性時間點是與事物開始時相一致的。 |
| 相同行數(shù)據(jù)的修改 | 如果此時兩個并發(fā)事物在修改同一行數(shù)據(jù)，先修改的事物將會給該行加行級鎖，另外一個事物將進入等待狀態(tài)，直到第一個事物操作該行結(jié)束。那么倘若第一個針對該行的修改操作最終被其事物回滾，第二個修改操作在結(jié)束等待后，將直接修改該數(shù)據(jù)。然而如果第一個操作是被正常提交的話，那么就需要進一步判斷該操作的類型，如果是刪除(delete)該行，第二個修改操作將直接被忽略。如果是update該行的記錄，第二個修改操作則需要重新評估該行是否依然符合之前定義的修改條件。 | 和讀已提交隔離級別的機制基本相同，只是在第一個修改操作提交后，第二個操作將不再區(qū)分之前的修改是delete還是update，而是直接并返回下面信息：Error: Can't serialize access due to concurrent update. 這是因為一個可串行化的事務(wù)在可串行化事務(wù)開始之后不能更改或者鎖住被其他事務(wù)更改過的行。因此，當應(yīng)用收到這樣的錯誤信息時，它應(yīng)該退出當前的事務(wù)然后從頭開始重新進行整個事務(wù)。在應(yīng)用程序中，也應(yīng)該有必要的代碼來專門處理該類錯誤。 |
最后需要說明的是，在絕大多數(shù)的情況下，讀已提交級別均可適用，而且該級別的并發(fā)效率更高。只有在比較特殊的情況下，才手工將當前的事物隔離級別調(diào)整為可串行化或可重復讀。
