在MySQL存储过程开发中，异常处理与事务回滚机制的实现，是保障数据一致性与业务逻辑可靠性的核心环节。许多开发者和数据库管理员在实际操作中常因细节疏忽而引入隐患。本文将深入解析几个关键误区，并提供清晰、可落地的解决方案。
DECLARE EXIT HANDLER FOR SQLEXCEPTION 必须与 START TRANSACTION 配合使用
首先需要明确一个核心原则：DECLARE EXIT HANDLER FOR SQLEXCEPTION 声明的作用范围仅限于当前显式开启的事务上下文内。如果未使用 START TRANSACTION 或 BEGIN 语句明确启动一个事务，则该异常处理器将不会生效。当错误发生时，MySQL不会触发此处理器，程序流程会继续执行后续语句，甚至可能自动提交已执行成功的操作，导致数据不一致。
一个典型的问题场景是：存储过程中先执行了一条UPDATE语句成功，随后执行INSERT时发生主键冲突（ERROR 1062）。由于未开启事务，异常处理器未被激活，过程会继续执行至最后的COMMIT，结果仅有UPDATE操作生效，破坏了数据的整体一致性。
- 声明顺序至关重要：务必在
DECLARE EXIT HANDLER声明之后、业务SQL语句之前，使用START TRANSACTION。顺序颠倒将导致处理器无法捕获后续语句抛出的异常。 - 避免依赖隐式事务：在默认
autocommit=1（自动提交）模式下，每条SQL语句本身就是一个独立事务。此时在存储过程中编写ROLLBACK语句是无效的。 - 警惕隐式提交语句：若过程中包含如
DROP TABLE、CREATE TABLE等DDL语句，它们会触发隐式提交，导致事务在该点自动结束。此后的ROLLBACK仅能回滚该DDL之后的操作，之前的更改已永久生效。
使用 RESIGNAL 而非 SIGNAL 或静默处理错误
仅在异常处理器中执行ROLLBACK是远远不够的。这种做法虽然回滚了事务，但调用方（例如Java应用或PHP脚本）很可能无法接收到任何错误信息，日志仅显示“存储过程执行成功”，给问题排查带来极大困难。
最规范的做法是使用RESIGNAL语句。它的作用是在执行回滚操作后，将捕获到的原始异常信息（包括SQLSTATE、MySQL错误码及错误描述文本）完整地重新抛出。这样，调用方就能准确获知故障根源。
需注意一个常见误区：避免手动构造错误。例如使用SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = ...抛出自定义错误。一方面，MESSAGE_TEXT超过128字符会引发Error Code: 1648错误；另一方面，原始、更精确的错误码会因此丢失，不利于问题定位。
- 优先选用
RESIGNAL：MySQL 5.5及以上版本原生支持，无需对错误信息进行截断或重新拼接，能保留完整的诊断信息。 - 诊断信息具有时效性：不要在处理器中先执行
GET DIAGNOSTICS将错误信息存入变量，随后又插入其他SQL语句（即使是SET赋值），最后才尝试RESIGNAL。因为任何非GET DIAGNOSTICS的语句都会清空之前获取的诊断信息。 - 错误日志的记录时机：如果确有记录错误日志的需求，必须在
GET DIAGNOSTICS之后，立即将信息插入一个已存在的、稳定的日志表中。注意，此插入操作本身不应包含COMMIT或ROLLBACK，以免干扰主事务。
避免使用 CONTINUE HANDLER 处理事务性异常
这是另一个高频陷阱。CONTINUE HANDLER的语义是“出错后，继续执行下一条语句”。在事务场景下，这种行为是极其危险的。
设想一个转账存储过程：先扣减A账户余额（UPDATE成功），再增加B账户余额（UPDATE时发生主键冲突或其他错误）。如果使用了CONTINUE HANDLER FOR SQLEXCEPTION，那么第二个UPDATE失败后，控制流会继续执行后面的COMMIT。最终结果是A账户的钱已被扣除，但B账户未收到，导致资金“消失”。
那么CONTINUE HANDLER完全无用吗？并非如此。它适用于一些非强一致性的批量操作场景，例如希望跳过某条重复记录继续处理后续数据的批量插入，且整个过程不涉及资金或核心状态变更。
- 事务内统一使用 EXIT HANDLER：凡是涉及事务完整性、数据一致性保障的操作，在事务体内应一律使用
DECLARE EXIT HANDLER FOR SQLEXCEPTION。 - 注意区分异常类型：
SQLEXCEPTION主要捕获如主键冲突、外键约束违反等“错误”。而游标遍历结束属于NOT FOUND条件，某些警告信息属于SQLWARNING，它们不会触发SQLEXCEPTION处理器，需要单独声明处理。 - 主键冲突属于 SQLEXCEPTION：像
ERROR 1062 (23000): Duplicate entry这类典型错误，本身就属于SQLEXCEPTION范畴，无需额外指定SQLSTATE。
应用层事务与存储过程事务的边界管理
此场景稍复杂。当你在应用层（例如使用PHP的mysqli或PDO扩展）通过begin_transaction()开启了一个事务，然后调用（CALL）一个存储过程时，事务的生命周期是由客户端连接控制的。
此时，若在存储过程内部再次编写START TRANSACTION，MySQL通常会报错（ERROR 1305）。而如果在过程内部编写COMMIT或ROLLBACK，它们通常会被忽略——MySQL会将其视为嵌套事务的尝试，但实际只响应最外层应用连接发出的提交或回滚指令。
因此，需要明确一个清晰的边界：要么，让存储过程自身管理完整的事务（适用于纯数据库层的独立逻辑单元）；要么，就让应用层统一负责开启事务、调用过程，并根据过程执行结果（或捕获的异常）来决定提交或回滚（这种模式更常见，控制力更强）。
- 混合模式需设置 autocommit：如果采用应用层控制事务的模式，务必确保连接的事务模式正确，通常在连接后执行
SET autocommit = 0以关闭自动提交。 - 避免“半手动”流程：在过程中通过
SELECT ... INTO赋值变量，再经IF判断决定是否COMMIT，这种模式容易遗漏错误分支或误判成功条件，导致应回滚的操作未回滚。 - 处理非异常类错误边界：有些操作，如
INSERT ... ON DUPLICATE KEY UPDATESQLEXCEPTION。对于此类场景，需依赖ROW_COUNT()函数判断实际影响行数，从而决定业务逻辑上的成功与否，这比简单的异常捕获要求更细致的处理。
