共計 2336 個字符，預計需要花費 6 分鐘才能閱讀完成。
本篇內容主要講解“PostgreSQL 事務處理機制原理”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“PostgreSQL 事務處理機制原理”吧!
背景說明：
以 ACID 為特征的事務是關系數據庫的一項重要的也是基本的功能。了解事務的實現原理不僅對數據庫產品本身的開發，對使用數據庫的應用程序的開發也有一定的益處。因此本次以 PostgreSQL 為對象簡單介紹了其事務實現的原理。
內容概述：
事務的實現原理可以解讀為 DBMS 采取何種技術確保事務的 ACID 特性。PostgreSQL 針對 ACID 的實現技術如下表所示。
表 1: 事務的 4 個特征 ACID 及響應的實現技術
ACID
實現技術
原子性
MVCC
一致性
約束（主鍵，外鍵等）
隔離性
MVCC
持久性
WAL
可以看到 PostgreSQL 中支撐 ACID 的主要是 MVCC 和 WAL 兩項技術。MVCC 和 WAL 是兩個比較成熟的技術，通常的關系數據庫中都有相應的實現，但每個數據庫具體的實現方式又存在很大差異。下面介紹一下 PostgreSQL 中 MVCC 和 WAL 的基本實現原理。
1. MVCC
MVCC(Multiversion Concurrency Control) 即多版本并發控制，它可以避免讀寫事務之間的互相阻塞，相比通常的封鎖技術可極大的提高業務的并發性能。PostgreSQL 中的 MVCC 實現原理可簡單概括如下：
1）數據文件中存放同一邏輯行的多個行版本（稱為 Tuple）
2）每個行版本的頭部記錄創建以及刪除該行版本的事務的 ID（分別稱為 xmin 和 xmax）
3）每個事務的狀態（運行中，中止或提交）記錄在 pg_clog 文件中
4）根據上面的數據并運用一定的規則每個事務只會看到一個特定的行版本
通過 MVCC 讀寫事務可以分別在不同的行版本上工作，因此能夠在互不沖突的情況下并發執行。
圖 1: 基于 MVCC 的數據更新舉例
2. WAL
當系統意外宕機后，恢復時需要回退未完成事務所做的更改并確保已提交事務所作的更改均已生效。在 PostgreSQL 中通過前面提到的 MVCC 很容易做到的第一點，只要把所有 pg_clog 文件中記錄的所有“運行中”的事務的狀態置為“中止”即可，這些事務在宕機時都沒有結束。對于第二點，必須確保事務提交時修改已真正寫入到永久存儲中。但是直接刷新事務修改后的數據到磁盤是很費時的，為解決這個問題于是引入了 WAL(Write-Ahead Log)。
WAL 的基本原理如下：
1）更新數據頁前先將更新內容記入 WAL 日志
2）異步刷新數據 Buffer 的臟頁和 WAL Buffer 到磁盤
3）Buffer 管理器確保絕不會先于對應的 WAL 記錄刷新臟數據到磁盤
4）事務提交時，將 WAL 日志同步刷新到磁盤
5）Checkpoint 發生時，將數據 Buffer 的所有臟頁刷新到磁盤
圖 2: 數據更新時的 Buffer 修改
圖 3: 更新提交和 Checkpoint 時的磁盤同步
Q A：
1、Q:PostgreSQL 中 DDL 支不支持事務？
A: 支持。PostgreSQL 中對 DDL 的處理方式和普通的 DML 類似，也是支持事務的。
2、 Q:PostgreSQL 中對 BLOB 數據的處理支不支持事務？
A: 支持。對 BLOB(bytea 或 large object) 數據的事務處理和普通數據的差別不大，但由于 BLOB 數據較大涉及 BLOB 的事務會產生很大的 WAL 日志文件。
3、Q:PostgreSQL 中很大的數據，比如 BLOB 如何在數據頁面中存儲？
A: 默認數據頁面的大小是 8K，當有很大數據時可能導致一個頁面放不下整個數據行。針對這種情況，PostgreSQL 采取一種叫做 TOAST 的技術，對于比較大的列只在行中放一個類似指針的東西，完整的數據放在另一個單獨的 TOAST 表中。在 TOAST 表中數據被切割成若干個 chunk, 每個 chunck 以一個數據行的形式存放。
4、Q:PostgreSQL 中可重復讀和可串行化隔離級別都不會出現幻讀那它們的區別是什么？
A: 根據 SQL 規約，能夠回避幻讀就已經滿足了“可串行化”隔離級別的要求。但是 SQL 規約定義的“可串行化”并不是嚴格意義上的可串行化，僅僅能回避幻讀不等于可以把并發執行的幾個事務轉化為幾個事務嚴格按某個順序先后執行 。PostgreSQL 中的可重復讀可以回避幻讀但不是嚴格意義上的可串行化，但是可串行化就是。順便說一下，Oracle 中的可串行化也不是嚴格意義上的可串行化，實際上它等價于 PostgreSQL 中的可重復讀。
5、Q:PostgreSQL 中事務 ID 分配完了怎么辦？
A: 從頭開始重新分配（實際上從 3 開始重新分配，0,1,2 已做為特殊用途，這稱之為事務回卷）。但這樣可能形成事務 ID 沖突的問題，PostgreSQL 中解決這個問題的措施有兩個。第一，定期清理留在數據文件中的過老的事務 ID，將它們統一設置為一個特殊值（2），在做事務新舊比較時，這個特殊的事務 ID 永遠比其他普通的事務 ID 舊。這就保證了系統中事務 ID 的范圍跨度不會過大。第二，在做事務新舊比較時不是簡單的比較兩個事務 ID 的算數值大小，而且考慮到了特殊事務 ID 和事務回卷的情況。比如根據內部的比較規則，無符號 INT 類型的事務 ID 0x00000005 比 0xFFFFFFFF 新。因為第一個措施已經保證了系統中事務 ID 間的跨度不會過大 (不超過 2^31)，所以 0x00000005 一定是事務 ID 回卷后的結果而 0xFFFFFFFF 還沒有發生回卷 (或者說比 0x00000005 少回卷一次)。
到此，相信大家對“PostgreSQL 事務處理機制原理”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
