Redshift SNAPSHOT隔离下MERGE重复插入问题及方案咨询

1. Redshift SNAPSHOT隔离与SQL Server的差异 #

Redshift的SNAPSHOT隔离和SQL Server并不完全一致。Redshift基于MVCC实现SNAPSHOT隔离，事务读取的是启动时的数据快照，但它没有SQL Server那种「提交时主动检测数据变更并回滚事务」的机制——只有当事务尝试修改已被其他事务修改的行时，才会触发冲突报错；而INSERT操作因为是新增行，不会触发这类冲突检测。

2. 重复行出现的原因 #

即使使用SNAPSHOT隔离，出现重复行的核心原因有两点：

• Redshift对MERGE的重写逻辑：Redshift确实会将MERGE拆分为独立的UPDATE和INSERT操作。当第一个Lambda的MERGE还在执行INSERT阶段 interior「Link在线 Whether>Read业务Calculate负责blob含　思考 Take （未提交），超时触发的第二个Lambda启动，由于SNAPSHOT隔离下它读取的是事务启动时的快照，看不到第一个事务未提交的INSERT行，因此会再次执行INSERT，最终两个事务都提交成功，导致重复行。
• 缺乏唯一性约束：因为没有对合并条件的两个整数列添加唯一性约束，Redshift无法在数据库层面阻止重复插入，并发或超时重发的INSERT操作都能成功写入。

3. SERIALIZABLE级别与最优方案 #

• 切换至SERIALIZABLE无法彻底解决问题：SERIALIZABLE隔离级别强制事务串行执行，但Redshift的SERIALIZABLE同样基于快照，不会主动检测INSERT的重复，且会大幅降低并发性能，不适合高吞吐量场景。

最优处理方案 #

• 添加唯一性约束：直接对合并条件的两个整数列创建UNIQUE CONSTRAINT，这是最根本的解决方案。当第二个事务尝试插入重复行时，Redshift会直接报错，阻止重复数据写入。注意：Redshift的唯一约束会自动生成对应索引。
• Lambda幂等性优化：给每个MERGE请求分配唯一请求ID，执行前先检查该ID是否已处理（比如维护请求日志表），确保同一请求不会被重复执行。
• 调整Lambda超时阈值：根据MERGE的平均执行耗时，调大Lambda超时时间，减少因超时导致的重发次数。
• 显式事务控制：在Lambda中用BEGIN/COMMIT包裹MERGE操作，确保其在原子事务中完成，但该操作需配合唯一性约束才能解决重复插入问题。

内容的提问来源于stack exchange，提问作者Alex Sikilinda