从补丁 198 开始，Amazon Redshift 将不再支持创建新的 Python UDF。现有的 Python UDF 将继续正常运行至 2026 年 6 月 30 日。有关更多信息，请参阅[博客文章](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)。

# 写入和读/写操作
<a name="c_write_readwrite"></a>

可通过决定何时以及如何运行不同类型的命令来管理并发写入操作的特定行为。以下命令与此讨论相关：
+ COPY 命令，可执行加载（初始或增量）
+ INSERT 命令，可一次性追加一个或多个行
+ UPDATE 命令，可修改现有行
+ DELETE 命令，可删除行 

COPY 和 INSERT 操作是纯写入操作。DELETE 和 UPDATE 操作是读/写操作（对于要删除或更新的行，必须先读取它们）。并发写入操作的结果取决于同时运行的具体命令。

UPDATE 和 DELETE 操作的行为方式不同，因为它们在执行任何写入操作前依赖最初的表读取。由于并发事务彼此不可见，因此，UPDATE 和 DELETE 必须读取上次提交的数据的快照。当第一个 UPDATE 或 DELETE 解除其锁定时，第二个 UPDATE 或 DELETE 需要确定它将使用的数据是否可能已过时。它不会过时，因为第二个事务不会在第一个事务解除其锁定之前获取其数据的快照。

## 涉及多个表的并发写入事务的潜在死锁情况
<a name="c_write_readwrite-potential-deadlock"></a>

当事务涉及更新多个表时，并发运行的事务始终可能在同时尝试写入同一组表时变为死锁状态。事务会在提交或回滚时一次性解除其所有表锁定；而不会逐一放弃锁定。

例如，假设事务 T1 和 T2 在大致相同的时间开始。如果 T1 开始对表 A 进行写入，而 T2 开始对表 B 进行写入，则这两个事务均可继续而不会发生冲突。但是，如果 T1 完成了对表 A 的写入操作并需要开始对表 B 进行写入，它将无法继续，因为 T2 仍保持对 B 的锁定。同样，如果 T2 完成了对表 B 的写入操作并需要开始对表 A 进行写入，它也无法继续，因为 T1 仍保持对 A 的锁定。由于两个事务都不能在提交其所有写入操作之前解除其锁定，因此两个事务都不能继续。为避免发生这种死锁情况，您需要小心安排并发写入操作。例如，您应始终在各事务中按相同顺序更新表，如果指定了锁定，则应先按相同的顺序锁定表，然后再执行任何 DML 操作。

## 涉及单个表的并发写入事务的潜在死锁情况
<a name="c_write_readwrite-potential-deadlock-single"></a>

在快照隔离环境中，对于同一个表运行并发写入事务时可能会发生死锁。当并发的 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 语句的事务，您可以在应用程序中加入重试逻辑来解决潜在的死锁。