ROLLBACK在存储过程中不生效的根本原因是事务未处于可回滚状态：未启动、已被隐式提交（如DDL）、或表引擎非InnoDB；需用DECLARE EXIT HANDLER配合ROLLBACK，且避免嵌套事务和标志变量假防护。
ROLLBACK 在存储过程中不生效，根本原因不是语法写错，而是事务压根没真正处于“可回滚”状态——要么没启动，要么已被悄悄提交，要么引擎根本不认事务。
存储过程里没配 DECLARE EXIT HANDLER
MySQL 存储过程不支持 try/catch，写了就报 ERROR 1064。异常发生时，默认行为是继续执行后续语句，不会自动中断、也不会自动回滚。
- 用
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION只是捕获错误，但不退出当前块，必须手动加IF判断 +ROLLBACK，否则事务悬在那儿 - 推荐用
DECLARE EXIT HANDLER FOR SQLEXCEPTION：一出错立刻跳出BEGIN...END块，再在 handler 里写ROLLBACK，才能确保回滚被执行 -
RESIGNAL不是必须，但建议加上，否则调用方收不到原始错误，只看到空返回或默认值
DDL 语句触发了隐式提交
哪怕你在 START TRANSACTION 之后，只要执行了 CREATE TABLE、ALTER TABLE、DROP TABLE、TRUNCATE TABLE、LOCK TABLES 或 GRANT，MySQL 就会立刻提交当前事务——之后再 ROLLBACK，只能回滚 DDL 之后的语句，前面的 DML 已经落地。
- 常见陷阱：在转账逻辑里顺手加个临时字段
ALTER TABLE accounts ADD COLUMN updated_at DATETIME，结果扣款已生效，回滚无效 - DDL 和 DML 必须拆开：建表/改表单独执行，业务逻辑另起事务
-
CREATE TEMPORARY TABLE同样会隐式提交，别以为“临时”就安全
表引擎不是 InnoDB
如果存储过程操作的表是 MyISAM 引擎，START TRANSACTION 和 ROLLBACK 全部被 MySQL 静默忽略，无报错、无提示，数据当场写死。
- 查引擎：
SHOW CREATE TABLE your_table，看输出里有没有ENGINE=InnoDB - 改引擎：
ALTER TABLE your_table ENGINE=InnoDB，注意该操作会锁表，线上慎用 - 新建表时务必显式指定：
CREATE TABLE t (...) ENGINE=InnoDB，别依赖默认（老版本 MySQL 默认是MyISAM）
嵌套调用导致事务被提前提交
MySQL 不支持真正嵌套事务。如果 A 过程调用 B 过程，而 B 过程内部写了 START TRANSACTION 和 COMMIT，那 B 的 COMMIT 会把 A 的整个事务一起提交掉——A 后续出错时，ROLLBACK 已无事务可滚。
- 避免在被调用过程中开启/提交事务，只在最外层过程控制事务边界
- 如需复用逻辑，把 DML 封装成无事务的子过程，由主过程统一包裹
START TRANSACTION～COMMIT/ROLLBACK - 不要在 handler 里只设标志变量、不写
ROLLBACK，那是假防护
最容易被忽略的一点：ROLLBACK 本身不报错，并不代表它成功了——它可能只是对着一个早已结束的事务静默返回。验证是否真回滚，得查数据，而不是看命令有没有报错。
