Redshift单表死锁排查：ETL并行化及锁表未阻止死锁的原因与解决

我来帮你拆解这个问题——Redshift的锁机制和你直觉里的可能有点不一样，你的LOCK TABLE没拦住死锁，大概率是锁的时机或者事务间的锁顺序出了问题，咱们一步步说：

为什么LOCK TABLE没阻止死锁？ #

Redshift的LOCK TABLE production_table;确实会请求ACCESS EXCLUSIVE锁（最严格的表级锁），理论上能阻塞所有其他对该表的DML/DDL操作，但有几个关键场景会让它失效：

1. 锁获取时机太晚
   你说流程是先创建大量临时表，再在事务里锁主表。问题在于：当你创建临时表的时候，事务已经启动了，但这时候其他ETL事务可能已经开始对production_table执行DML（比如DELETE/INSERT），并持有了行级（或数据块级）锁。此时你的LOCK TABLE会进入等待状态，等待那些事务释放锁。如果恰好那些事务之后也尝试获取表级锁（比如它们的流程也有LOCK TABLE步骤），就会出现循环等待：你的事务等它们的行锁，它们的事务等你的表锁，直接触发死锁。

2. Redshift锁的兼容性规则
   表级锁和行级锁是可以共存的。如果其他事务先执行了DML并持有行锁，你的LOCK TABLE不会强制中断它们，只会等待。而如果你的事务此时还持有其他资源锁（虽然临时表是会话私有，但创建临时表时会涉及系统目录的锁，极端情况下可能和其他事务的系统目录锁冲突），也可能触发死锁。

解决方法 #

针对你的ETL场景，这里有几个靠谱的修复方案：

• 把LOCK TABLE放在事务的最开头
  不要先创建临时表再锁主表，而是启动事务后第一时间执行LOCK TABLE production_table;，确保在任何其他事务能碰主表之前，就拿到排他锁。这样后续的临时表创建、DELETE/INSERT操作都能在锁的保护下进行，不会出现其他事务抢占行锁的情况。
  示例流程：

  BEGIN TRANSACTION;
  -- 先锁主表，再做其他操作
  LOCK TABLE production_table;
  -- 创建临时表
  CREATE TEMP TABLE temp_table1 AS SELECT ...;
  -- 删除主表数据
  DELETE FROM production_table WHERE ...;
  -- 插入临时表数据
  INSERT INTO production_table SELECT * FROM temp_table1;
  COMMIT;
  

• 统一所有ETL流程的锁顺序
  如果有多个ETL任务同时操作production_table，必须确保所有任务都遵循先锁表，再执行DML的顺序。绝对不能有的任务先DML再锁表，有的先锁表再DML——这种不一致的锁顺序是死锁的重灾区。

• 考虑用TRUNCATE替代DELETE（如果适合你的场景）
  如果你是要全量替换主表数据，TRUNCATE TABLE production_table;会自动获取ACCESS EXCLUSIVE锁，而且比DELETE快得多（因为它不逐行删除，直接清空数据块）。不过要注意TRUNCATE是DDL操作，无法回滚，所以必须确保ETL的临时表数据是正确的再执行。

• 查死锁日志定位根源
  可以查询Redshift的STL_DEADLOCKS系统表，查看死锁发生时的事务ID、锁类型、等待关系，能精准找到是哪个事务和你的流程冲突：

  SELECT * FROM stl_deadlocks ORDER BY deadlock_time DESC LIMIT 10;
  

内容的提问来源于stack exchange，提问作者Hans Z