H2数据库1.4.197批量操作时出现SYS表并发更新失败问题

这个问题我之前在处理H2并发批量操作时也遇到过，结合H2 1.4.197的特性和你的场景，主要可以从以下几个方向排查和解决：

1. 升级H2到稳定版本 #

H2 1.4.197存在一些已知的并发操作下系统表（SYS）锁竞争的bug，这些问题在后续的1.4.200及更高版本中已经得到修复。建议优先升级H2版本，这是最直接有效的解决方案。

2. 调整Merge操作的并发策略 #

• 提前锁定目标行：在执行merge前，先通过SELECT * FROM tableName WHERE col1 = ? AND col2 = ? FOR UPDATE锁定要操作的记录，避免并发merge时对同一行的竞争扩散到系统表层面。
• 拆分批量任务：将一次性处理1000条记录的任务拆分为更小的批次（比如每100条一批），减少同一时间点的并发操作数量，降低系统表的访问压力。

3. 优化连接池配置 #

虽然你设置了最大连接数为100，但如果所有连接同时执行merge操作，会加剧系统表的并发冲突。可以：

• 限制并发执行merge的线程数，比如通过线程池控制，避免同时有超过20-30个连接在执行批量merge；
• 调整连接池的maxIdle和minIdle参数，保持适当的空闲连接，减少连接频繁创建销毁带来的额外系统表操作。

4. 确保表约束和索引的正确性 #

• 明确创建col1和col2的唯一约束：执行ALTER TABLE tableName ADD CONSTRAINT uk_tableName_col1_col2 UNIQUE (col1, col2)，而不是仅依赖merge语句中的key(col1,col2)子句。H2在处理merge时需要明确的唯一约束来判断记录是否存在，模糊的定义可能导致系统表频繁更新引发冲突。
• 重建相关索引：如果索引存在碎片或异常，可能会导致merge操作时系统表的额外写入，尝试DROP INDEX idx_tableName_col1_col2; CREATE UNIQUE INDEX idx_tableName_col1_col2 ON tableName(col1, col2);来修复。

5. 调整事务隔离级别 #

当前如果使用的是默认的READ COMMITTED隔离级别，可以尝试提升到REPEATABLE READ，减少并发下元数据的不一致性，从而降低系统表的竞争概率。注意这个调整可能会带来一定的性能损耗，需要根据实际场景测试。

错误提示中的"Concurrent update in table 'SYS'"通常是因为多个并发操作同时修改H2的系统元数据表（比如记录索引、约束状态的表），而旧版本的H2在这种场景下的锁机制不够完善。

内容的提问来源于stack exchange，提问作者Yauvaraj Rimal