13.4. 應用層數據完整性檢查 · PostgreSQL 中文文檔 9.3

# 13.4\. 應用層數據完整性檢查關于使用讀已提交事務的數據完整性強制執行業務規則是很難的，由于數據視圖從每個語句偏移，如果發生寫入沖突，則單一語句可以不限制自身到語句快照。當可重復讀事務在執行期間有穩定的數據表視圖，使用MVCC數據一致性檢查的快照有一個微妙的問題，涉及一些被稱為_讀/寫沖突_的東西。如果一個事務寫入數據，并且并發事務嘗試讀取同一數據（無論寫之前還是之后），它不能看到其他事務的工作。讀者似乎首先被執行，無論哪個先被啟動或先被提交。如果是這樣，這是沒有問題的，但如果讀者也寫由并發事務讀取的數據，則現在有一個前面已提到的事務似乎運行著的事務。如果已經被執行的事務最后首先被提交，出現在事務執行順序圖中，這樣一個循環是很容易的。當這樣一個循環出現時，完整性檢查將不能正常工作，而沒有一定的幫助。正如[Section 13.2.3](#calibre_link-727)提及到的，可串行化事務是可重復讀事務，其中添加了讀/寫沖突危險模式的非阻塞監測。當這個模式被監測時，有可能導致明顯的執行順序周期，其中所涉及到的事務回滾以打破這個周期。 ## 13.4.1\. 可串行化事務執行一致性如果序列化事務隔離級別是用于所有寫和所有讀，這需要數據一致視圖，沒有其他努力來確保一致性。來自其他環境的軟件書面使用序列化事務確保一致性應該在PostgreSQL這方面"只是工作"。當使用這種技術時，如果應用軟件完成框架，其中回滾到可串行化失敗的地方進行自動重啟事務，它可以避免為應用參數產生不必要的負擔。設置`default_transaction_isolation`到`可串行化`是一個很好的主意。明智的采取一些措施確保沒有其他可用的事務隔離級別，或者是無意的或者破壞完整性檢查，通過觸發器中的事務隔離級別檢查。參見[Section 13.2.3](#calibre_link-727)獲取性能建議。 | **Warning** | |:--- | | 這一級別的完整性保護使用序列化事務還沒有延伸到熱備模式（[Section 25.5](#calibre_link-1047)）。因此，那些采用熱備方式可能要使用可重復讀，并且主庫上明確鎖。 | ## 13.4.2\. 明確阻塞鎖的執行一致性當可能進行非串行化寫入時，要保證一行當前實際存在和避免其被同時更新，我們必須使用`SELECT FOR UPDATE`, `SELECT FOR SHARE`或者合適的`LOCK TABLE`語句。`SELECT FOR UPDATE`和`SELECT FOR SHARE` 只是對其它的并發更新鎖住返回的行，而`LOCK TABLE`保護整個表。當從其它環境向PostgreSQL里用可串行化模式移植應用時一定要把這些問題考慮進去。還要注意來自其他環境的這些轉變事實：`SELECT FOR UPDATE` 不能保證并發事務不更新或刪除已選擇的行。為了這樣做，PostgreSQL中你必須更新行，即使沒有值需要被改變。來自獲取同一個鎖或者執行`UPDATE`或者`DELETE`的`SELECT FOR UPDATE` _暫時阻塞_ 其他事務可能影響鎖定行，但是一旦事務持有這個鎖提交或者回滾，被阻塞事務將繼續做沖突操作，除非當鎖被持有的時候，執行實際`UPDATE`行。在MVCC非串行化下，全局有效性檢查需要一些額外的考慮。比如，一個銀行應用可能會希望檢查一個表中的所有扣款總和等于另外一個表中的加款總和，同時兩個表還會被活躍地更新。在讀已提交模式下比較兩個連續的`SELECT sum(...)`命令的結果是不可靠的，因為第二個查詢很可能會包含第一個沒計算的事務提交的結果。在一個可串行化的事務里進行兩個求和則給出在可串行化事務開始之前提交的所有事務產生的精確的結果— 但我們還是會合理地置疑在結果提交的時候，它們是否還相關。如果可串行化事務本身在試圖做一致性檢查之前進行了某些變更，那么檢查的有用性就更加值得討論了，因為現在它包含了一些(但不是全部)事務開始后的變化。在這種情況下，一個仔細的人會希望鎖住所有需要檢查的表，這樣才能獲得一個無可置疑的當前現狀的圖像。一個`SHARE`模式(或者更高級)的鎖保證在被鎖定表中除了當前事務之外，沒有未提交的更新。還要注意如果我們依賴明確鎖定來避免并發更新，那么我們應該使用讀已提交模式，或者是在可串行化模式里在執行命令之前小心地獲取鎖。在可串行化事務里獲取的鎖保證了不會有其它正在運行的修改該表的事務存在，但是如果事務看到的快照提前獲取了鎖，那么它可能提前把一些現在已經提交的改變放到表中。一個可串行化事務的快照實際上是在它的第一個查詢或者數據修改命令(`SELECT`, `INSERT`, `UPDATE`, or `DELETE`)開始的時候凍結的，因此我們可以在快照凍結之前明確獲取鎖。