SQL Server存储过程中可通过WHILE循环+TRY...CATCH+WAITFOR DELAY手动实现类似Java的try-catch-retry：在TRY内执行事务操作，CATCH中用ERROR_NUMBER()=1205判断死锁、XACT_STATE()≠0时ROLLBACK，@retry计数并延时后重试，超限则THROW。
SQL Server 存储过程中怎么模拟 Java 的 try-catch-retry？
SQL Server 本身没有内置的「自动重试」语法，但可以通过 WHILE 循环 + TRY...CATCH + 延迟（WAITFOR DELAY）手动实现类似 Java 中 retryOnException 的行为。关键不是“有没有 retry 关键字”，而是控制重试次数、间隔和退出条件。
常见错误是把重试逻辑写在 CATCH 外面，导致异常未捕获就进入下一轮；或者忽略事务状态，重试时遇到 XACT_STATE() = -1（不可提交事务）还强行执行，直接报错 The current transaction cannot be committed。
- 必须在
TRY块内执行可能失败的操作（如远程调用、链接服务器查询、INSERT冲突等） - 每次进入
CATCH后，先用IF XACT_STATE() 0 ROLLBACK TRAN清理事务状态 - 用变量（如
@retry_count）计数，配合BREAK或CONTINUE控制循环 - 重试前加
WAITFOR DELAY '00:00:01'，避免瞬间打爆目标资源（尤其是链接服务器或外部 API）
PostgreSQL 存储过程里能用 EXCEPTION + LOOP 实现重试吗？
可以，但仅限于 PL/pgSQL 函数（CREATE OR REPLACE FUNCTION），且必须声明为 LANGUAGE plpgsql。注意：PostgreSQL 的存储过程（CREATE PROCEDURE）在 11+ 才支持，且不支持 EXCEPTION 块——它只能用 CALL 触发事务性操作，异常必须由调用方处理。
所以真要重试，得写成函数，并确保调用方（比如另一个 DO 块或上层应用）不吞掉它的返回值。容易踩的坑是：在 EXCEPTION 里没重置状态变量，导致无限循环；或对非预期错误（如权限不足）也重试，掩盖真正问题。
- 用
LOOP ... EXIT WHEN @retry_count > 3;包裹主逻辑 -
EXCEPTION WHEN SQLSTATE 'XX000' THEN可捕获特定错误码，比泛用WHEN OTHERS更安全 - 每次循环开始前设
PERFORM pg_sleep(0.5);，单位是秒，别写成毫秒 - 函数末尾必须有
RETURN，哪怕只是RETURN true;，否则调用时报control reached end of function without RETURN
MySQL 存储过程中如何避免重试导致死锁或超时？
MySQL 没有原生 TRY...CATCH，只能靠 DECLARE ... HANDLER 捕获错误，再结合 REPEAT 或 WHILE 实现重试。但它的 handler 是「语句级」的，无法跨语句捕获——也就是说，如果一个事务里有多条语句，只对最后一条设 handler，前面的失败不会触发它。
更麻烦的是：MySQL 的锁等待超时默认只有 50 秒（innodb_lock_wait_timeout），重试逻辑若没检查锁冲突错误（SQLSTATE '40001' 或错误码 1205），可能每次都在等锁，最终全失败。
- handler 必须声明在所有语句之前，且针对具体错误码：
DECLARE CONTINUE HANDLER FOR SQLSTATE '40001' - 重试前用
SELECT SLEEP(1)（注意是函数，不是命令），避免密集轮询 - 每次重试前用
GET DIAGNOSTICS CONDITION 1 @sqlstate = RETURNED_SQLSTATE;确认错误类型，别盲目重试 - 务必在重试循环外显式开启事务（
START TRANSACTION），并在成功后COMMIT，失败后ROLLBACK
跨数据库重试逻辑要注意哪些兼容性陷阱？
不同数据库对「事务中断后能否继续执行」的处理差异极大：SQL Server 允许 CATCH 后新开事务；PostgreSQL 函数中一旦异常，当前事务块就结束，后续语句属于新事务；MySQL 的 handler 触发后，会跳过当前语句继续执行下一条——这意味着你得手动控制流程，不能依赖隐式恢复。
最常被忽略的一点：重试不是万能解药。网络抖动、临时锁表适合重试；但主键冲突、数据校验失败、权限错误这些，重试只会重复失败。建议只对明确可恢复的错误码重试（如 SQL Server 的 1205、PostgreSQL 的 40001、MySQL 的 1205），其他一律抛出。
还有就是日志——别只靠 PRINT 或 RAISE NOTICE，它们在某些客户端里会被丢弃。真要调试，得写入表（如 log_retry_attempts），记录时间、错误码、重试次数和 SQL 片段。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
