rollback在存储过程中常无效，根本原因是事务上下文未真正建立：需调用方显式开启事务、autocommit=0、全程无隐式提交、所有表均为innodb引擎。
存储过程里写 ROLLBACK 不一定生效，真正起作用的前提是：调用方已显式开启事务、autocommit=0、全程没触发隐式提交、所有表都是 InnoDB 引擎。
为什么 ROLLBACK 在存储过程中经常“没反应”
不是语法错，而是事务上下文根本没建立起来。常见失效场景：
-
autocommit=1（默认值）下，每条语句自动提交，ROLLBACK找不到可滚的变更 - 存储过程内部写了
START TRANSACTION，但调用方没开事务——MySQL 会强制在过程退出时隐式提交 - 过程里执行了
ALTER TABLE、CREATE INDEX等 DDL，触发隐式COMMIT，前面所有 DML 就锁死不可逆 - 涉及 MyISAM 表，哪怕只有一张，整段事务就失去原子性，
ROLLBACK对它无效 -
DECLARE EXIT HANDLER FOR SQLEXCEPTION捕获了异常，但没配START TRANSACTION—— handler 是刹车片，不是发动机
正确做法：调用方启动事务 + 过程内用 SAVEPOINT 控制粒度
事务边界必须由外部控制，存储过程只负责逻辑和局部回滚点。例如注册流程含用户插入、日志记录、邮件触发，邮件失败不该删用户：
START TRANSACTION;
INSERT INTO users (name) VALUES ('alice');
SAVEPOINT sp_after_user;
INSERT INTO logs (msg) VALUES ('user created');
-- 假设此处调用发邮件失败，抛出异常
-- 触发 handler 后执行：ROLLBACK TO sp_after_user;
-- 用户记录保留，日志回退
COMMIT;
注意：SAVEPOINT 不能跨存储过程传递，每个过程需独立管理自己的保存点。
验证回滚是否真实生效的两个硬指标
别只看有没有报错，要查数据状态和事务元信息：
- 执行
ROLLBACK后立刻SELECT相关表，确认变更消失；若用SELECT ... FOR UPDATE，可能读到旧快照，得换普通SELECT - 查
INFORMATION_SCHEMA.INNODB_TRX：运行SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE trx_mysql_thread_id = CONNECTION_ID()，结果为空才代表事务真正结束 - 如果仍看到活跃事务记录，说明
ROLLBACK语句本身没执行，或被后续隐式提交覆盖了
最容易被忽略的是：handler 里 ROLLBACK 成功不代表业务逻辑安全——它只对当前连接、当前未提交事务生效；如果过程里开了新连接、用了临时表、或调用了其他含 DDL 的过程，回滚范围就失控了。
