防死锁需嵌入流程控制：统一资源访问顺序、拆分长事务为可提交子单元、设置合理锁等待超时并主动重试、避免跨事务状态依赖。
在复杂的清算流水线中，事务回滚死锁往往不是因为单个SQL出错，而是多个并发事务交叉更新同一组账户、订单或批次记录时，因加锁顺序不一致、持有时间过长或等待策略缺失引发的循环等待。要确保事务不因死锁而被动回滚，关键在于把“防死锁”嵌入流程控制逻辑本身，而非仅依赖数据库自动检测与牺牲性回滚。
统一资源访问顺序
清算流水线常涉及多账户扣款、多科目记账、多批次对账等操作。若不同事务按任意顺序更新账户A和账户B（如T1先A后B，T2先B后A），极易触发死锁。必须在流程编排层强制标准化顺序：
- 对所有需并发修改的实体（如账户ID、订单号、批次号）定义全局排序规则，例如按数值升序或字符串字典序
- 在事务启动前，对本次操作涉及的所有主键ID进行预排序，再按序执行UPDATE/INSERT
- 使用存储过程或应用层协调器封装该逻辑，禁止业务代码直接裸写无序SQL
拆分长事务为可提交子单元
清算通常包含“校验→冻结→记账→通知→归档”等阶段，全程放在一个事务里会持锁过久。应将逻辑切分为语义完整、可独立提交的子事务：
- 校验与冻结可合并在第一个事务中完成并提交，释放对应行锁
- 记账操作单独成事务，失败时只重试该环节，不影响前置状态
- 通知与归档异步化，不参与核心事务，避免I/O阻塞锁持有
- 每个子单元之间用幂等标识（如流水号+状态码）衔接，支持断点续跑
设置合理锁等待超时并主动重试
依赖InnoDB默认50秒锁等待易导致清算任务卡顿甚至超时。应在流程控制器中显式管理等待行为：
- 将innodb_lock_wait_timeout设为3～8秒（非全局，按业务场景动态调整）
- 捕获Deadlock异常（MySQL错误码1213）后，不直接向上抛出，而是由流程引擎触发有限次指数退避重试（如100ms、300ms、1s）
- 重试前刷新本地缓存或重新查询最新余额/状态，避免基于陈旧数据重复冲突
- 累计重试达阈值（如3次）则标记为“人工干预”，转入补偿队列而非持续争抢
避免跨事务状态依赖与用户交互
清算流程若掺杂外部系统回调、人工审核确认或定时延迟动作，会导致事务长时间挂起，增加死锁概率：
- 所有需外部响应的环节（如风控拦截、人工复核）必须退出当前事务，以状态机方式持久化中间态
- 禁止在事务内调用HTTP同步接口或等待消息队列ACK
- 使用状态字段（如status IN ('pending', 'processing', 'success', 'failed')）驱动后续步骤，而非靠锁阻塞等待
- 对账类操作尽量采用快照读（READ COMMITTED隔离级别），减少gap lock范围
