本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
Aurora DSQL 的並行控制
並行功能可讓多個工作階段同時存取和修改資料，而不會影響資料完整性和一致性。Aurora DSQL 提供 PostgreSQL 相容性，同時實作現代、無需鎖定的並行控制機制。其可透過快照隔離維持完整的 ACID 合規，以確保資料一致性和可靠性。
Aurora DSQL 的主要優點是無需鎖定架構，可消除常見的資料庫效能瓶頸。Aurora DSQL 可防止緩慢交易封鎖其他操作，並消除死結的風險。這種方法讓 Aurora DSQL 特別適合效能和可擴展性至關重要的高輸送量應用程式。
並行控制回應
Aurora DSQL 使用開放式並行控制 (OCC)，其運作方式與傳統的鎖定型系統不同。OCC 會評估遞交時的衝突，而不是使用鎖定。這個遞交時間衝突評估的程序也稱為判斷。當 Aurora DSQL 偵測到衝突時，它會傳回具有 SQLSTATE 程式碼 的 PostgreSQL 序列化失敗40001。回應訊息包含識別衝突類型的 OCC 程式碼：
- OC000 — 資料衝突
-
嘗試修改相同資料列的兩個交易。具有最早遞交時間的交易會成功，而衝突的交易會收到 OC000 回應：
ERROR: change conflicts with another transaction (OC000) (SQLSTATE 40001) - OC001 — 結構描述衝突
-
工作階段的快取結構描述目錄已過期。當 Aurora DSQL 偵測到自工作階段載入其快取以來目錄版本已變更，且交易無法安全地重新基底至目前版本時，交易會收到 OC001 回應：
ERROR: schema has been updated by another transaction (OC001) (SQLSTATE 40001)修改結構描述目錄的任何操作都可能導致 OC001 回應，包括 DDL 陳述式，例如
CREATE TABLE和ALTER TABLE，以及GRANT和REVOKE陳述式。如需詳細資訊，請參閱Aurora DSQL 的 DDL 和分散式交易。
設計您的應用程式以實作重試邏輯來處理這些回應。理想設計模式為等冪，並盡可能讓交易重試成為優先求助方法。建議邏輯類似於，標準 PostgreSQL 鎖定逾時或死結情況下的中止和重試邏輯。不過，使用 OCC 時，您的應用程式必須更頻繁地執行此邏輯。
資料衝突類型
由於 Aurora DSQL 並行控制機制， SELECT ... FOR UPDATE和 SELECT ... FOR KEY SHARE子句會在遞交時透過樂觀的衝突偵測產生結果，而不是鎖定。在 Aurora DSQL 中，當一個交易寫入資料列，而另一個使用上述其中一個子句讀取它時，根據交易使用的欄，可能會在遞交時間出現衝突。下列子句決定 Aurora DSQL 如何偵測這些衝突。
金鑰欄定義
索引鍵資料欄是屬於唯一、非部分、非表達式索引的成員的資料欄。所有其他資料欄都是非索引鍵資料欄。
SELECT ... FOR UPDATE-
宣告 Aurora DSQL 會將選取的資料列視為交易寫入資料列。如果另一個交易在同一列
SELECT ... FOR KEY SHARE上執行UPDATE、SELECT ... FOR UPDATE、DELETE或 並先遞交，則執行的交易SELECT ... FOR UPDATE會失敗並顯示OC000回應。此子句與資料列的任何並行寫入，以及並行FOR UPDATE或FOR KEY SHARE讀取衝突。 SELECT ... FOR KEY SHARE-
宣告交易取決於所選資料列的索引鍵資料欄。如果另一個交易刪除資料列、變更其索引鍵資料欄，或先執行
SELECT ... FOR UPDATE和遞交，則執行的交易SELECT ... FOR KEY SHARE會失敗並顯示OC000回應。UPDATE與非索引鍵資料欄並行不會衝突。
Aurora DSQL 不支援 NO KEY UPDATE或 FOR SHARE子句。不過，DML 會隱含使用 NO KEY UPDATE機制。下列矩陣摘要說明兩個存取相同資料列衝突的並行交易何時發生。X 表示兩個操作衝突：任何交易遞交最後失敗並顯示 OC000 回應。空白儲存格表示兩個交易都可以遞交。
| 作業 | INSERT、DELETE、 UPDATE（索引鍵欄） 或 SELECT ... FOR UPDATE |
UPDATE （僅限非索引鍵資料欄） |
SELECT ... FOR KEY SHARE |
|---|---|---|---|
INSERT、DELETE、 UPDATE（索引鍵欄） 或 SELECT ... FOR UPDATE |
X | X | X |
UPDATE （僅限非索引鍵資料欄） |
X | X | |
SELECT ... FOR KEY SHARE |
X |
最佳化交易效能的指導方針
為了最佳化效能，請將單一索引鍵或小型索引鍵範圍上的激烈爭用性降至最低。若要達成此目標，請使用下列指導方針設計結構描述，將更新分散至叢集索引鍵範圍：
-
為您的資料表選擇隨機主索引鍵。
-
避免使用會提高單一索引鍵爭用性的模式。即使交易量增加，此方法也能確保最佳效能。
