Redshift重复插入问题复现困难及原因排查求助

为什么Serializable隔离级别下还会出现重复？ #

Redshift的Serializable隔离级别基于快照隔离实现：每个事务启动时会获取一个数据库快照（对应事务开始时刻的状态），后续所有读取都基于这个快照。

当两个并行事务同时执行你的INSERT语句时，它们的快照里都看不到对方待插入的Account值，因此都会通过WHERE NOT EXISTS的过滤条件，最终各自插入相同的Account，导致重复。

Redshift的Serializable实现不会检测这类**写偏斜（Write Skew）**场景——即两个事务基于同一快照读取，后续修改操作导致数据不一致的情况。你本地复现失败，是因为测试环境的事务执行时机、数据量和生产环境不同，要么触发了Redshift的冲突检测抛出隔离违规，要么事务有先后顺序没产生并行写入。

修复建议 #

1. 加唯一约束（最可靠的底层保障） #

给AccountLookup表的Account字段添加唯一约束，从数据库层面强制唯一性：

ALTER TABLE AccountLookup ADD CONSTRAINT uq_accountlookup_account UNIQUE (Account);

后续若有并行事务尝试插入重复值，其中一个会因违反约束失败，确保数据不会出现重复。

2. 改用UPSERT语法 #

替换原有的INSERT语句为ON CONFLICT DO NOTHING的UPSERT，让数据库自动处理重复逻辑：

BEGIN;
    INSERT INTO AccountLookup (Account)
    SELECT DISTINCT Account FROM Staging db
    ON CONFLICT (Account) DO NOTHING;
END;

这个语法无需手动写NOT EXISTS，原子性更强，能有效避免并行插入导致的重复。

3. 串行化任务执行 #

如果该插入逻辑是ETL定时任务，可通过调度工具（如Airflow）确保同一时间只有一个任务实例在运行，从根源避免并行写入冲突。

内容的提问来源于stack exchange，提问作者Dhilip H