SQL Server中TRY...CATCH不会自动回滚事务，必须显式执行ROLLBACK TRANSACTION；PostgreSQL异常后事务块即失效，需用SAVEPOINT实现局部回滚；MySQL的HANDLER不自动控制事务，须手动提交或回滚。
SQL Server 中 TRY...CATCH 里回滚事务必须显式写 ROLLBACK TRANSACTION
很多人以为只要进了 CATCH 块，事务就自动回滚了——不是的。SQL Server 不会自动回滚未提交的事务，哪怕发生了运行时错误、执行被中断，或者 RAISERROR 抛出异常。如果没手动 ROLLBACK，事务仍处于活动状态，连接可能被挂起，后续语句报错 The current transaction cannot be committed and cannot support operations that write to the log file。
实操建议：
-
TRY块开头必须先用BEGIN TRANSACTION显式开启事务 -
CATCH块第一件事就是检查XACT_STATE()：值为-1表示事务不可提交（已损坏），必须ROLLBACK；值为1表示可提交，但通常你仍要回滚；值为0表示无活动事务（比如错误发生在事务外） - 不要依赖
@@TRANCOUNT判断是否该回滚——它在某些错误下不准确，XACT_STATE()才是权威依据
PostgreSQL 存储过程（PL/pgSQL）中异常后事务状态不可恢复
PostgreSQL 的函数/过程一旦触发异常（EXCEPTION 块捕获），当前事务块（transaction block）即进入失败状态，后续任何 DML 都会报错 current transaction is aborted, commands ignored until end of transaction block。这不是“能回滚就能继续”的逻辑，而是整个事务块作废。
实操建议：
- 不要在同一个事务块里混用业务逻辑和异常处理——把需要原子性的操作封装进单独的
BEGIN ... EXCEPTION ... END子块 - 子块里的
EXCEPTION只能处理该子块内的错误，不影响外层事务；外层若需回滚，得靠上层逻辑控制，不能指望子块“救活”事务 - 想实现类似 SQL Server 的“局部回滚+继续执行”，只能靠
SAVEPOINT：在关键操作前设点，出错时ROLLBACK TO SAVEPOINT，而不是全事务回滚
MySQL 存储过程中 DECLARE HANDLER 对事务控制力很弱
MySQL 的 DECLARE CONTINUE HANDLER FOR SQLEXCEPTION 只负责跳转到错误处理逻辑，它本身不终止事务、不回滚、不改变 autocommit 状态。更麻烦的是：如果存储过程在 autocommit=0 模式下调用，且内部没显式 COMMIT 或 ROLLBACK，那么调用者看到的仍是“未结束事务”，极易引发锁等待或连接堆积。
实操建议：
- 在
HANDLER内必须自己判断并执行ROLLBACK或COMMIT，不能只做日志或变量赋值 - 优先使用
START TRANSACTION显式开启，而非依赖会话级autocommit设置，避免环境差异导致行为不一致 - 注意 MySQL 8.0+ 支持
GET DIAGNOSTICS获取错误码，但对事务状态无影响，仅用于记录
跨数据库迁移时最容易忽略的事务边界一致性
把 SQL Server 的存储过程直接迁到 PostgreSQL 或 MySQL，最常崩在事务控制上：SQL Server 允许在 CATCH 后继续执行其他语句（只要不碰事务），而 PG/MySQL 要么强制退出函数，要么要求你用 SAVEPOINT 细粒度控制。一个看似简单的“记录日志 + 回滚 + 返回错误码”逻辑，在不同数据库里实际执行路径完全不同。
实操建议：
- 别复用同一套异常处理模板——每个数据库的事务生命周期模型不同，得按目标方言重写控制流
- 上线前务必用真实并发场景压测：模拟锁超时、唯一键冲突、死锁等典型错误，看事务是否真释放、连接是否回收、日志是否完整
- 如果业务强依赖“失败后还能尝试备选路径”，那就别把所有逻辑塞进一个存储过程，拆成多个可独立提交的步骤，由应用层协调
