SQL任务重试需通过唯一业务键查成功状态、事务内写入processing预置状态、乐观锁更新success终态、失败留痕并设超时兜底，确保幂等与数据一致。
SQL任务重试时，若不记录状态或缺乏幂等控制，极易导致重复执行、数据错乱或丢失。核心思路是：用数据库自身事务能力 + 显式状态标记 + 幂等设计，让重试安全可控，最终达成一致。
重试前先查状态（基于唯一业务键）
每次任务触发前，先根据业务唯一标识（如 order_id、task_id、external_no）查询是否已存在成功记录。不是查“有没有执行过”，而是查“是否已成功完成”。成功标志建议是明确的状态字段（如 status = 'success'）或带时间戳的完成记录。
- SELECT 1 FROM task_log WHERE biz_key = ? AND status = 'success' LIMIT 1
- 查到结果 → 直接跳过，返回成功；没查到 → 继续执行
- 避免用 COUNT(*) 或模糊条件，防止幻读或性能问题
执行中写入预置状态（事务内落库）
真正执行业务逻辑前，在同一数据库事务中插入或更新一条“待处理”记录（如 status = 'processing'），并带上唯一 biz_key 和当前时间。这条记录既是锁，也是日志。
- INSERT INTO task_log (biz_key, status, created_at) VALUES (?, 'processing', NOW()) ON CONFLICT (biz_key) DO NOTHING
- PostgreSQL 可用 upsert；MySQL 用 INSERT ... ON DUPLICATE KEY UPDATE
- 失败回滚时，该记录也不会残留，保证状态干净
成功后原子更新为终态（含校验）
业务逻辑执行完毕且提交前，将对应记录更新为 success，并校验原状态是否仍为 processing（防并发覆盖）。可用 WHERE 子句做乐观锁式更新：
- UPDATE task_log SET status = 'success', updated_at = NOW() WHERE biz_key = ? AND status = 'processing'
- 检查影响行数：若为 0，说明已被其他实例抢先完成，当前重试应终止
- 不依赖额外锁表或 SELECT FOR UPDATE，减少阻塞
异常时留痕并设超时兜底
执行失败需记录 error_msg、retry_count、next_retry_at（如 5 秒后），并限制最大重试次数（如 3 次）。对长时间卡在 processing 的记录，加定时任务扫描清理或告警：
- UPDATE task_log SET status = 'failed', error_msg = ?, retry_count = retry_count + 1 WHERE biz_key = ? AND status = 'processing'
- 定时 SQL：SELECT * FROM task_log WHERE status = 'processing' AND updated_at
- 失败后可人工介入，或触发补偿流程（如发消息通知下游核对）
基本上就这些。不复杂但容易忽略的是：状态字段必须有索引，biz_key 必须唯一约束，所有写操作必须走事务。靠数据库保证原子性，比应用层加锁或外部协调器更轻量、更可靠。
