目錄

事務管理：確保操作的原子性

事務的概念與重要性

事務的啟動與提交

事務的回滾（ROLLBACK）（

數據一致性與隔離級別

隔離級別的解釋

設置隔離級別

錯誤處理與事務的高級策略

異常處理（SAVEPOINT & EXCEPTION）

自動提交與手動控制

注意

并發控制與鎖

悲觀鎖(Pessimistic Lock)

樂觀鎖(Optimistic Lock)

---

事務管理：確保操作的原子性

? ? 事務是數據庫操作的基本單位，確保數據的一致性和完整性，本節深入探討事務的定義、啟動與結束。

事務的概念與重要性

事務是一系列操作的集合，這些操作要么全部成功，要么全部失敗，保持數據的原子性。理解事務對于防止數據不一致至關重要。

事務的啟動與提交

• BEGIN：顯式開啟一個新的事務。

BEGIN;
INSERT INTO accounts (balance) VALUES (1000);

• COMMIT：提交事務，永久保存更改。

  COMMIT;

  事務的回滾（ROLLBACK）（

• 當事務中的一部分操作失敗時，使用ROLLBACK撤銷所有已做的更改。

  /*由于錯誤，賬戶余額減少的操作被撤銷，保持數據的原始狀態。*/
  BEGIN;
  UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
  -- 假設這里出現了一個錯誤
  ROLLBACK;

  數據一致性與隔離級別

  理解事務的隔離級別是處理并發操作時保持數據一致性的關鍵。

  隔離級別的解釋

• READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE：從低到高依次提供更強的隔離性，但也可能影響并發性能。

• 示例說明隔離級別差異：

  -- 假設有兩個事務T1和T2同時操作賬戶表
  -- 在SERIALIZABLE級別下，T1的讀取不會看到T2未提交的更改，確保數據的一致性。

  設置隔離級別

• 顯示當前會話的隔離級別：

SHOW transaction_isolation;

• 修改隔離級別：

  SET SESSION transaction_isolation TO 'REPEATABLE READ';

  錯誤處理與事務的高級策略

  掌握如何在遇到錯誤時優雅地處理事務，以及使用保存點和異常塊等高級特性。

  異常處理（SAVEPOINT & EXCEPTION）

• 使用SAVEPOINT標記事務中的特定點，以便在遇到錯誤時回滾到該點而不是整個事務。

  BEGIN;
  SAVEPOINT before_update;
  UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
  -- 如果更新失敗
  ROLLBACK TO SAVEPOINT before_update;

  自動提交與手動控制

? ? ?在PostgreSQL中，事務的管理對于數據一致性和可靠性至關重要。以下是關于PostgreSQL自動提交與手動控制事務的區別：

特性	自動提交模式	手動提交模式
默認行為	默認開啟（大多數情況下，除非特定配置更改）	需要手動開啟，某些版本或配置下可能為默認
事務邊界	每個SQL語句執行完后自動提交，形成獨立事務	事務開始于BEGIN，結束于COMMIT或ROLLBACK
控制粒度	粗粒度，每個操作自動完成	細粒度，允許一組操作作為一個整體提交或回滾
數據修改即時性	數據修改立即生效，無法撤銷單個語句	數據修改直到COMMIT才對外可見，可控制回滾
示例代碼	直接執行SQL語句，如?INSERT INTO table VALUES (...);	BEGIN; <SQL操作>; COMMIT;?或?ROLLBACK;
適用場景	快速操作，無需復雜事務邏輯或高度一致性的簡單應用	需要精確控制事務邊界，保證數據完整性和一致性

注意

• 自動提交簡化了編程模型，減少了忘記提交事務的風險，但可能不適合需要多個操作原子性完成的場景。
• 手動提交提供了更細粒度的控制，適用于需要執行多條SQL語句且這些語句必須全部成功或全部失敗的情況。
• 在PostgreSQL中，可以通過設置AUTOCOMMIT參數來改變默認行為，例如使用SET AUTOCOMMIT TO OFF;來關閉自動提交，進入手動提交模式。

并發控制與鎖

? ? 在PostgreSQL中，悲觀鎖和樂觀鎖是兩種不同的并發控制策略，用于處理多用戶環境下對共享資源的訪問，以避免數據不一致性和并發沖突。

悲觀鎖(Pessimistic Lock)

? ? ?悲觀鎖假定在事務處理過程中數據很可能發生并發沖突，因此采取一種預防性的鎖定策略。在開始讀取或修改數據前，悲觀鎖會先鎖定數據，確保在整個事務期間，沒有其他事務能夠修改這些數據。這種方式可以有效防止并發沖突，但可能會降低系統的并發性能，因為資源被鎖定期間，其他需要訪問這些資源的事務會被阻塞等待。

在PostgreSQL中，可以使用SELECT ... FOR UPDATE或SELECT ... FOR SHARE語句顯式地申請悲觀鎖。這些鎖會在事務結束時自動釋放，無論是通過COMMIT還是ROLLBACK。例如：

BEGIN;
SELECT * FROM my_table WHERE id = 1 FOR UPDATE;
-- 進行一些業務邏輯處理...
COMMIT;

這段代碼會鎖定id為1的行，阻止其他事務修改或刪除這行數據，直到當前事務結束。

樂觀鎖(Optimistic Lock)

樂觀鎖則假設在事務處理過程中數據并發沖突的概率較低，因此它不會一開始就鎖定數據。相反，樂觀鎖會在事務開始時記錄數據的一個版本標識（通常是通過在表中添加一個版本字段，如version），然后在事務提交前檢查數據的版本是否發生變化。如果版本未變，說明沒有沖突，事務可以正常提交；如果有其他事務已經修改了數據（即版本號不同），則當前事務通常會回滾，由應用程序決定如何處理這種情況（如重新嘗試事務）。

在PostgreSQL中，樂觀鎖的實現依賴于應用程序的邏輯，通常涉及在更新時檢查數據版本。例如：

• 讀取數據時，同時讀取版本字段：

SELECT * FROM my_table WHERE id = 1;

• 更新數據時，比較版本字段：

  BEGIN;
  UPDATE my_table 
  SET column = value, version = version + 1 
  WHERE id = 1 AND version = original_version_from_read;-- 如果影響行數為0，表示版本不匹配，可能有并發修改
  GET DIAGNOSTICS result = ROW_COUNT;
  IF result = 0 THEN-- 處理并發沖突，如回滾事務或重新嘗試
  END IF;
  COMMIT;

  ? ? 在這個例子中，version字段在更新時會增加，更新語句只有在原始讀取的版本與數據庫中的版本相匹配時才會執行成功，從而檢測并發修改。

? ? ? 悲觀鎖適用于并發沖突頻繁、對數據一致性和實時性要求較高的場景，而樂觀鎖適用于并發沖突較少、追求高并發性能的場景。選擇哪種鎖策略需根據實際應用場景權衡。