MySQL事务异常处理需结合保存点、异常捕获和应用层机制。首先使用SAVEPOINT设置保存点实现部分回滚；其次在存储过程中通过DECLARE HANDLER捕获SQLEXCEPTION或特定SQLSTATE，结合GET DIAGNOSTICS进行条件处理；再者在应用层用try-catch包裹事务，出错时显式ROLLBACK，成功则COMMIT；最后务必关闭autocommit以确保事务原子性，避免操作意外提交。
MySQL事务在执行过程中可能会遇到各种异常，比如死锁、唯一键冲突、连接中断等。为了保证数据的一致性和完整性，合理处理事务中的异常非常关键。下面介绍几种常见的MySQL事务异常处理方法。
使用SAVEPOINT设置保存点进行部分回滚
在复杂事务中，如果某一步出错但不想完全回滚整个事务，可以使用SAVEPOINT来设置中间节点。
操作方式：
- 通过
SAVEPOINT savepoint_name;定义一个保存点 - 发生错误后执行
ROLLBACK TO SAVEPOINT savepoint_name;回滚到该点 - 之后可继续提交或进一步处理
这种方式适合需要局部纠错而不影响整体流程的场景。
捕获异常并进行条件处理（存储过程内）
在MySQL存储过程中，可以通过DECLARE HANDLER来捕获特定错误并执行相应逻辑。
常见用法：
-
DECLARE CON：发生异常时执行指定语句并继续
TINUE HANDLER FOR SQLEXCEPTION ...
-
DECLARE EXIT HANDLER FOR SQLSTATE '45000' ...：针对特定状态码退出或处理 - 结合
GET DIAGNOSTICS获取错误详情，便于日志记录
例如检测主键冲突（错误码1062），可以选择忽略或更新已有记录。
应用层配合try-catch机制处理事务异常
大多数情况下，事务控制由应用程序（如Java、Python、PHP）发起。应在代码中使用事务包裹SQL操作，并通过异常捕获机制判断是否回滚。
典型流程：
- 开启事务（
BEGIN或对应API） - 执行多条SQL语句
- 若任意一步抛出异常，则调用
ROLLBACK - 成功则提交（
COMMIT）
这样能确保即使数据库未自动回滚，应用也能主动干预。
注意自动提交与显式事务的管理
MySQL默认autocommit=1，每条语句独立提交。进行事务处理前应关闭自动提交：SET autocommit = 0;
否则即使写了ROLLBACK也可能无效，因为前面的操作已经永久生效。
完成事务后记得恢复设置或明确提交/回滚，避免长事务占用资源。
基本上就这些。关键是根据业务需求选择合适的异常响应策略，结合数据库和应用层共同保障数据一致性。
