关键在于对齐连接可靠性、批量执行语义与幂等边界：JDBC与连接池双控超时，按业务拆解可重试单元，结合batch_id与状态快照实现请求级幂等，并依SQLState分类处理异常。
Java 批量数据库操作中，既要防连接超时中断，又要保证重试不破坏数据一致性——关键不是“一边配超时、一边加重试”，而是把连接可靠性、批量执行语义、幂等边界三者对齐。
连接超时必须在 JDBC 层 + 连接池层双控
批量操作耗时长，单靠 connectTimeout（建连）和 socketTimeout（读写）还不够，必须配合连接池生命周期管理：
-
socketTimeout 要大于单批最大执行时间：比如一批最多处理 500 条，预估 SQL 执行+网络往返不超过 15 秒，那就设
&socketTimeout=20000，留出缓冲； -
HikariCP 的 max-lifetime 必须比 MySQL 的 wait_timeout 小 2~3 分钟：例如服务端
wait_timeout = 600（10 分钟），则 Java 端设max-lifetime=540000（9 分钟），避免连接被服务端静默断开后还留在池中； -
开启 keepalive-time（HikariCP ≥3.2.1）：如
keepalive-time=30000，让空闲连接定期发心跳，主动探活，比被动等到执行时报错更早发现问题。
批量操作不能无脑重试，必须定义“可重试单元”
整批失败后直接 retry all，风险极高：可能部分数据已落库，重试导致重复；也可能事务已提交一半，重试引发主键冲突或状态错乱。应按业务语义拆解：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 若批量是“插入订单明细”，每条明细有唯一业务键（如
order_id + sku_id），可用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE，把冲突交给数据库裁决； - 若批量含状态变更（如“将 100 个订单从待支付设为已支付”），需先查当前状态再更新，用 WHERE status = 'pending' 做条件，确保更新行数可预期，失败时能精准定位哪几条卡住；
- 避免在事务内做跨库/远程调用，否则超时边界不可控；批量内部尽量保持纯 DB 操作，把外部依赖移到事务外。
客户端重试 + 幂等，核心是“请求级唯一标识 + 状态快照”
不是所有批量都适合全局幂等，但支付回调、对账同步这类强一致场景必须落地：
立即学习“Java免费学习笔记（深入）”；
- 每次批量请求携带服务端生成的 batch_id（非 UUID，建议含业务类型+时间戳+序列号，如
pay_callback_20260916_000123），并持久化到一张batch_execution表； - 执行前先查该
batch_id是否存在且状态为success，存在则跳过整批；若状态为processing，可等待或直接报错，避免并发写； - 执行中每条记录写入时，同时记录其
record_id + batch_id + status到去重表，后续重试可跳过已成功子项，实现“部分幂等”。
异常分类处理比统一重试更可靠
不是所有失败都该重试，要根据 SQLException 的 SQLState 或错误码区分：
-
通信类异常（如
08S01、Communications link failure）：大概率是连接闪断，可立即重试 1~2 次，间隔 100~500ms； -
死锁/锁等待超时（如
40001、1205）：属于瞬时资源竞争，适合指数退避重试（如 100ms → 300ms → 900ms）； -
主键冲突/唯一约束失败（如
23000）：说明数据已存在，不是故障而是业务事实，应记录并跳过，而非重试； -
语法错误或表不存在（如
42S02）：属代码或部署问题，重试无意义，需告警介入。
