事务回滚在存储过程中生效的前提是显式开启事务、禁用自动提交、避免隐式提交及确保引擎支持，否则ROLLBACK无效；需由调用方启动事务，配合SAVEPOINT实现局部回滚，并通过查表和INNODB_TRX验证实际效果。
事务回滚在存储过程中能保证数据一致性，但前提是它必须真正“在事务里”——而多数人写的存储过程其实根本没进事务。
为什么 ROLLBACK 在存储过程中经常失效
最常见的情况是：你写了 START TRANSACTION，也调用了含 ROLLBACK 的存储过程，但回滚没发生。原因往往不是语法错，而是事务上下文断了。
-
autocommit=1下，存储过程内每条语句自动提交，ROLLBACK无事可滚 - 存储过程用
DECLARE EXIT HANDLER捕获异常后执行ROLLBACK，但没配START TRANSACTION—— 手动开启事务必须在调用存储过程之前，而不是藏在过程内部 - 过程里执行了 DDL（如
ALTER TABLE），触发隐式COMMIT，前面所有 DML 就再也回滚不了 - 过程用了多个表，其中一张是
MyISAM引擎，哪怕其他都是InnoDB，整段事务也失去原子性
DECLARE EXIT HANDLER 必须配合显式事务边界
不能只靠异常处理器“兜底”，它只是个刹车片，不是引擎。事务得先启动，再挂上这个刹车。
- 调用方负责
START TRANSACTION，不是存储过程自己BEGIN -
EXIT HANDLER中的ROLLBACK只对当前连接、当前事务生效；跨连接或已提交的变更它管不了 - 建议在 handler 里加日志记录，比如
INSERT INTO error_log VALUES (...)，否则失败无声，调试困难 - 避免在 handler 里再执行可能出错的操作（如写日志表时磁盘满），否则会掩盖原始错误
用 SAVEPOINT 控制局部回滚范围
复杂业务逻辑里，并非所有步骤都该一起回滚。比如注册用户要插 users、发邮件、记日志，发邮件失败不该删掉刚建的用户。
- 在关键分界点设保存点：
SAVEPOINT sp_after_user_insert - 后续操作失败时，只回滚到该点：
ROLLBACK TO sp_after_user_insert -
RELEASE SAVEPOINT不影响事务整体，只清理保存点本身 - 注意：
SAVEPOINT不能跨存储过程调用边界——每个过程需独立管理自己的保存点
验证 ROLLBACK 是否真生效的两个硬指标
别信“没报错就成功”，要看数据状态和事务元信息。
- 执行
ROLLBACK后立刻查表，确认变更消失；尤其注意SELECT是否带FOR UPDATE，否则可能读到旧快照 - 查
INFORMATION_SCHEMA.INNODB_TRX表：SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_mysql_thread_id = CONNECTION_ID()，结果为空才代表事务真正结束 - 如果仍看到活跃事务记录，说明
ROLLBACK语句本身没执行（比如被 handler 跳过）、执行失败（权限不足、语法错），或根本不在事务中
事务不是开关，是上下文。存储过程里的 ROLLBACK 是个被动动作，它依赖外部事务开启、引擎支持、无隐式提交干扰——漏掉任意一环，数据一致性就只剩侥幸。
