MySQL执行含自增主键INSERT查询时断连的状态同步及重试方案咨询

问题核心 #

自动提交模式下，INSERT执行成功后的响应因网络闪断丢失时，客户端无法感知服务端实际执行状态：如果服务端已经完成写入，重试自增主键INSERT会生成重复的冗余数据，且表中无其他唯一键时无法通过业务字段直接去重。

可行方案 #

方案1：新增全局请求唯一标识（推荐，通用场景适配） #

这是对业务侵入最低的通用幂等方案，适合封装SQL操作层的需求：

• 给所有需要执行INSERT的表新增request_id字段，类型为VARCHAR(64)，同时添加唯一索引
• 底层SQL操作层每次处理INSERT请求前，本地生成全局唯一ID（UUID、雪花ID均可）作为本次请求的request_id，自动拼接进INSERT语句，示例：

  Insert into xxx Values(0, 1, 'xxx-unique-req-id-123')
  

• 当触发网络异常重试逻辑时，先执行查询判断请求是否已经执行过：

  SELECT COUNT(*) FROM xxx WHERE request_id = 'xxx-unique-req-id-123'
  

  • 若查询结果大于0，说明上次请求已经执行成功，直接返回成功即可，无需重试插入
  • 若查询结果等于0，说明上次请求未执行成功，再执行INSERT操作

该方案的所有逻辑都可以封装在SQL操作层内部，上层业务完全无感知，可覆盖所有写操作的幂等重试场景。

方案2：显式事务+幂等提交（无需改表结构） #

如果不希望修改表结构，可以调整提交逻辑适配重试需求：

• 关闭自动提交模式，所有INSERT操作都用显式事务包裹，执行流程为：开启事务 → 执行INSERT → 执行COMMIT
• 如果执行COMMIT阶段出现网络异常，直接重试COMMIT操作即可：MySQL的事务提交是天然幂等的，重复提交同一个事务不会产生重复写入的副作用
• 如果COMMIT返回明确失败（比如事务因连接断开已经回滚），再重新执行整个「开启事务→INSERT→COMMIT」的流程。

方案3：利用自增ID属性辅助判断（临时应急方案） #

如果既不能改表也不能改事务逻辑，可以用表自增属性做模糊判断：

• 网络异常重连后，先查询当前表的下一个待分配自增ID：

  SHOW TABLE STATUS LIKE 'xxx'
  

  从返回结果中取Auto_increment字段值，记为next_auto_id
• 用待插入的业务字段值查询小于next_auto_id的记录中是否有匹配数据：

  SELECT id FROM xxx WHERE 业务字段 = 1 AND id < ${next_auto_id} LIMIT 1
  

  • 有匹配结果说明上次插入已成功，直接返回
  • 无匹配结果再执行重试插入

该方案仅适用于业务上不存在完全相同字段的业务数据场景，如果允许同值数据存在，可能出现误判，仅作为临时应急方案使用。

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