Java批量执行语句时单条执行状态的检测与处理咨询

核心结论先明确：不是所有语句都会标记失败 #

最终结果取决于你采用的执行模式：

• 如果用单事务包裹所有语句执行，多数数据库（比如MySQL InnoDB）会在某条触发UNIQUE约束失败时直接回滚整个事务，所有已执行的语句也会被撤销，相当于全部失败。
• 如果是分条/小批量独立执行，或者用数据库提供的「冲突跳过/更新」特性，那么只有触发约束的语句会失败，其他语句可以正常执行成功。

如何检测并区分成功/失败语句 #

1. 单条捕获异常（精准追踪）

把大批量拆成单条或极小批量执行，在代码里捕获数据库抛出的UNIQUE约束异常（不同数据库错误码不同：MySQL是1062，PostgreSQL是23505，SQL Server是2601）。每执行一条就记录状态：成功则标记，失败则记录下这条语句的内容和冲突原因（比如哪个唯一键重复了）。

• 优点：能精准定位每一条失败的语句，方便后续针对性处理；
• 缺点：执行效率比纯批量低，适合对数据准确性要求极高的场景。

2. 利用数据库批量操作特性（高效处理）

大部分主流数据库都提供了专门处理UNIQUE冲突的语法，既能保证执行效率，又能统计处理结果：

• MySQL：
  • 使用INSERT IGNORE INTO ...：违反约束的行会被直接跳过，成功的正常插入。执行后用SELECT ROW_COUNT();获取成功插入的行数，和总条数对比就能知道失败数量，但没法定位具体哪条失败。
  • 使用INSERT INTO ... ON DUPLICATE KEY UPDATE：违反约束时，会对现有行执行更新操作（比如UPDATE col = VALUES(col)）。同样用ROW_COUNT()获取受影响行数，也能通过业务逻辑判断哪些行是插入、哪些是更新。
• PostgreSQL：
  • 使用INSERT INTO ... ON CONFLICT (unique_col) DO NOTHING：跳过冲突行；或者DO UPDATE SET ...执行更新。配合RETURNING *可以返回所有成功处理的行，和原始数据对比就能找出没被处理的冲突行。
• SQL Server：
  • 使用MERGE INTO ... WHEN MATCHED THEN UPDATE ... WHEN NOT MATCHED THEN INSERT ...：既能处理插入，又能在冲突时执行更新，同样可以通过输出子句获取处理状态。

3. 预处理校验（提前规避冲突）

在执行批量操作前，先把要操作的唯一键（比如用户名、手机号）提取出来，用一个查询语句找出数据库中已存在的重复值。把这些重复的数据单独拎出来，剩下的无冲突数据正常执行批量操作，重复的部分后续单独处理（比如提示用户、更新现有数据）。

• 优点：从源头避免执行时的冲突，执行效率最高；
• 缺点：如果在预处理到执行的间隙有其他操作插入了重复数据，还是可能出现冲突，需要考虑并发场景的锁或者事务隔离级别。

4. 事务与批量的平衡策略

如果不想牺牲太多效率，又要避免全量回滚，可以把大批量拆成多个小事务（比如每100条一个事务）。每个小事务内如果出现冲突，只回滚当前小批次的语句，其他批次不受影响。然后对失败的小批次再拆成单条执行，定位具体失败的语句。

内容的提问来源于stack exchange，提问作者Veeresh Devireddy