Amazon Redshift 將不再支援從修補程式 198 開始建立新的 Python UDFs。現有 Python UDF 將繼續正常運作至 2026 年 6 月 30 日。如需詳細資訊，請參閱部落格文章。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

寫入和讀/寫操作

透過決定何時與如何執行不同的類型的命令，您可以管理並行寫入操作的特定行為。以下是與此討論相關的命令：

COPY 和 INSERT 操作是純寫入操作。DELETE 和 UPDATE 操作是讀取/寫入操作 (必須先讀取列，才能將其刪除或更新)。並行寫入操作的結果取決於並行執行的特定命令。

UPDATE 和 DELETE 操作有不同的行為，因為它們仰賴於執行任何寫入之前的初始資料表讀取。由於並行交易彼此看不見對方，UPDATE 和 DELETE 必須從上次認可讀取資料的快照。第一個 UPDATE 或 DELETE 釋出其鎖定時，第二個 UPDATE 或 DELETE 必須判斷要使用的資料是否可能過時。它將不會過時，因為第二個交易不會取得其資料的快照，直到第一個交易已釋出其鎖定為止。

涉及多個資料表的並行寫入交易潛在死結情況

只要交易牽涉到一個以上資料表的更新，當其都嘗試寫入相同的資料表集時，並行執行的交易就有可能變成死結。交易會在認可或復原時一次釋出其所有資料表鎖定；它不會一次撤回一個鎖定。

例如，假設交易 T1 和 T2 在大約相同的時間開始。如果 T1 開始寫入資料表，而 T2 開始寫入資料表 B，這兩個交易都可以繼續而不衝突。不過，如果 T1 完成寫入資料表並且必須開始寫入資料表 B，它將無法繼續，因為 T2 仍在 B 上保有鎖定。同樣地，如果 T2 完成寫入資料表 B 並且必須開始寫入資料表 A，它將無法繼續，因為 T1 仍在 A 上保有鎖定。因為這兩項交易都可釋出其鎖定，直到其所有寫入操作都認可，因此兩項交易都無法繼續。為了避免這類的死結，您必須謹慎排程並行寫入操作。例如，您應該一律以相同的順序更新交易中的資料表，同時，如果指定鎖定，在執行任何 DML 操作之前，以相同的順序鎖定資料表。

涉及單一資料表的並行寫入交易潛在死結情況

在快照隔離環境中，死結可能發生於在相同資料表上執行並行寫入交易時。當並行 INSERT 或 COPY 陳述式共用鎖定並正在進行，而另一個陳述式需要對相同資料表執行需要獨佔鎖定的操作 (UPDATE、DELETE、MERGE 或 DDL 操作) 時，快照隔離死結就會發生。

請考量下列情況：

交易 1 (T1)：

INSERT/COPY INTO table_A;

交易 2 (T2)：

INSERT/COPY INTO table_A; 
            <UPDATE/DELETE/MERGE/DDL statement> table_A

當具有 INSERT 或 COPY 操作的多項交易在共用鎖定的情況下於相同資料表上並行執行，而其中一項交易遵循其純寫入操作且具有需要獨佔鎖定的操作 (例如 UPDATE、MERGE、DELETE 或 DDL 陳述式) 時，就可能發生死結。

若要避免在這些上述情況下發生死結，您可以將需要獨佔鎖定的陳述式 (UPDATE/MERGE/DELETE/DDL 陳述式) 分開放到不同的交易，如此所有 INSERT/COPY 陳述式都可同時進行，而需要獨佔鎖定的陳述式可在其之後執行。或者，對於在相同資料表上具有 INSERT/COPY 陳述式和 MERGE/UPDATE/MERGE 陳述式的交易，您可以在應用程式中包含重試邏輯，以解決潛在死結。