PostgreSQL中什么是事務

這篇文章主要介紹PostgreSQL中什么是事務，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

　　一、什么是事務?

　　事務可以看作是一個操作的有序集，這些操作應作為整體來對待，即集內所有的操作都成功的時候，該事務才被認為是成功的，否則的話，即使其中只有一個操作失敗，該事務也會被認為是不成功。如果所有的操作全部成功，那么事務就會被提交，這時它的所作的修改才能被所有其他數據庫進程所用。如果操作失敗，該事務就會被回滾，同時事務內部所有已完成操作所做的修改會被全部撤銷。在事務提交之前，一次事務期間所作的修改，只對擁有此事務的進程可用。之所以這樣做，是為了防止其他線程使用了事務修改的數據后，事務隨后又發生了回滾，從而導致數據完整性錯誤。
 

　　事務功能是企業數據庫的關鍵所在，因為許多業務流程是由多步組成的，下面我們以在線購物為例進行說明。在結帳時，顧客的購物車會跟現有庫存進行比對，以確保有現貨。接下來，顧客必須提供收費與交貨信息，這時就需要檢查相應的信用卡是否可用，并從中扣款。然后，需要從產品庫存清單中扣除相應的數量，如果庫存不足，還應向采購部門發出通知。在這些步驟中，只要有一步發生錯誤，那么所有修改都不應該生效。假設沒有現貨的情況下，還是從顧客的信用卡中扣了款的話，那么顧客會很生氣，問題就會很嚴重了。同樣地，作為在線商家，當信用卡無效的時候，您也肯定不希望從存貨清單中扣除此次顧客選擇的商品數量，或者因此而發出相應的采購通知。

　　我們這里所說的事務，必須滿足四大要件：

　　l 原子性：事務所有的步驟必須全部成功;否則，任何步驟都不會被提交。

　　l 一致性：事務所有的步驟必須全部成功;否則，所有的數據都會恢復到事務開始之前的狀態。

　　l 隔離性：在事務完成之前，所有已執行的步驟必須與系統保持隔離。

　　l 持久性：所有提交的數據，系統必須加以恰當保存，并保證萬一系統發生故障時仍能將數據恢復到有效狀態。

　　PostgreSQL的事務支持功能完全遵循上述四項基本原則(有時候人們簡稱為ACID)，從而能夠有效保證數據庫的完整性。

二、PostgreSQL的事務隔離

　　PostgreSQL的事務支持是通過通常所說的多版本并發控制或者MVCC方法實現的，也就是說，每當事務進行處理時，它看到的是自己的數據庫快照，而非底層數據的實際狀態。 這使得任何給定的事務無法看到其它已經啟動但是尚未提交的事務對數據所作的部分修改。這項原則就是所謂的事務隔離。

　　SQL標準規定了三種屬性以用來確定一個事務處于四級隔離級別的哪一級，這些屬性如下所示：

　　l 臟讀：一個事務讀取了另一個未提交的并行事務寫的數據

　　l 不可重復讀：當一個事務重新讀取前面讀取過的數據時，發現該數據已經被另一個已提交的事務修改過

　　l 幻讀：一個事務重新執行一個查詢時，返回一套符合查詢條件的行，發現這些行因為其他最近提交的事務而發生了改變

　　這三種情況確定了一個事務的隔離級別，所有四種水平如表1所示。

　　表1 SQL標準事務隔離級別

#FormatImgID_0#

　　PostgreSQL允許您請求四種可能的事務隔離級別中的任意一種。但是在內部，實際上只有兩種可用的隔離級別，分別對應讀已提交和可串行化。如果你選擇了讀未提交的級別，實際上你用的是讀已提交，在你選擇可重復的讀級別的時候，實際上你用的是可串行化，所以實際的隔離級別可能比你選擇的更嚴格。雖然這看起來是有悖于我們的直覺，但是SQL標準的確允許這樣做，因為四種隔離級別只定義了哪種現象不能發生，但是沒有定義那種現象一定發生，所以除了不允許的事務特性之外，所有的特性都是允許的。舉例來說，如果您請求可重復讀模式，那么該標準只是要求您不準臟讀以及不可重讀，但是卻沒有要求允許幻讀。因此，可串行化事務模式滿足可重復讀模式的要求，即使它跟定義沒有完全吻合。因此，您應當確切的知道，當您請求讀未提交模式的時候，您實際得到的卻是讀已提交模式;而當您請求可重復讀的時候，實際得到的是可串行化模式。您還應當意識到，默認情況下，如果您沒有請求一個特定的隔離級別，那么您得到的將是讀已提交隔離級別。

　　下面我們了解一下讀已提交和可串行化之間的主要區別。在讀已提交模式下SELECT 查詢只能看到該查詢開始之前提交的數據而永遠無法看到未提交的數據或者是在查詢執行時其他并行的事務提交的改變;不過 SELECT 的確看得見同一次事務中前面更新的結果，即使它們還沒提交也看得到。實際上，一個 SELECT 查詢看到一個在該查詢開始運行的瞬間該數據庫的一個快照。請注意兩個相鄰的 SELECT 命令可能看到不同的數據，哪怕它們是在同一個事務里，因為其它事務會在第一個SELECT執行的時候提交。當一個事務處于可串行化級別的時候，一個 SELECT 查詢只能看到在該事務開始之前提交的數據而永遠看不到未提交的數據或事務執行中其他并行事務提交的修改;不過，SELECT 的確看得到同一次事務中前面的更新的效果，即使事務還沒有提交也一樣。這個行為和讀已提交級別是不太一樣，它的 SELECT 看到的是該事務開始時的快照，而不是該事務內部當前查詢開始時的快照。這樣，一個事務內部后面的SELECT命令總是看到同樣的數據。這意味著，讀已提交模式下一個事務內部后面的SELECT命令可以看到不同的數據，但是在可串行化模式下卻總是看到同樣的數據。

　　對于以上區別，請讀者一定弄清楚。雖然剛看上去有些復雜，但是只要抓住兩個要點，理解起來還是很容易的：首先，PostgreSQL運行事務的并發運行，也就是說一個事務執行的時候，并不妨礙另一事務對相同數據操作。其次，一定注意快照的概念，事務提交前操作的是數據快照而非數據庫本身，同時注意不同隔離級別使用的是何時的快照——事務開始之前的快照，還是事務內部操作開始之前的快照?我想只要抓住了以上要點，我們就能很好的把握各種隔離級別之間的區別了。

　　上面介紹了事務的基本概念，接下來我們開始演示如何在PostgreSQL客戶端中使用事務。

三、創建示例表

　　下面，我們通過一個具體的在線交易應用為例來闡述上面介紹的事務概念。為此，我們需要先給這個示例程序在名為company的數據庫中創建兩個表：participant和trunk。同時，我們還會介紹各個表的用途和結構。建好表后，我們還需為它們填入一些樣本數據，具體如下所示。

　　我們首先創建Participant表，這個表用來存放參與物品交換者的信息，包括他們的姓名、電子郵件地址和可用現金：

1 CREATE TABLE participant (
2 participantid SERIAL,
3 name TEXT NOT NULL,
4 email TEXT NOT NULL,
5 cash NUMERIC(5,2) NOT NULL,
6 PRIMARY KEY (participantid)
7 );
8 CREATE TABLE<span

以上是“PostgreSQL中什么是事務”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！