mysql存储过程事务回滚失败主因是错误处理器缺失、自动提交未关闭、ddl语句隐式提交及myisam引擎不支持事务；需在start transaction后定义declare handler for sqlexception并显式rollback，禁用ddl，确保表为innodb且连接autocommit=0。
MySQL存储过程里事务回滚失败，通常不是语法写错了，而是被几个隐蔽机制“悄悄绕过”了——最常见的是错误处理没接管、自动提交没关、或者DDL语句混进来了。
存储过程中没启用错误处理器（DECLARE HANDLER）
MySQL默认遇到SQL错误不会中断执行，也不会自动触发回滚。哪怕你写了BEGIN ... END块，只要没显式声明错误怎么处理，过程就继续往下跑，ROLLBACK根本不会被执行。
- 必须用
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION捕获异常，并在其中写ROLLBACK - 仅靠
IF NOT FOUND或SQLWARNINGhandler 不够，它们不覆盖主错误路径 - handler 要在事务
START TRANSACTION之后、DML之前定义，否则可能失效
存储过程里执行了隐式提交语句（如 ALTER、CREATE、GRANT）
一旦过程里出现任何DDL或DCL语句，MySQL会在该语句执行前自动提交当前事务——此时再调ROLLBACK，只能回滚它之后的操作，前面的DML早已落地。
-
ALTER TABLE、DROP INDEX、CREATE PROCEDURE都会触发隐式提交 -
GRANT、REVOKE、SET PASSWORD同样不可逆 - 检查过程体：把DDL/DCL拆到事务外，只在事务块内放
INSERT/UPDATE/DELETE
连接级 autocommit=1 没关闭，且没手动开事务
即使存储过程里写了START TRANSACTION，如果客户端连接本身是autocommit=1，而过程又没显式调用SET autocommit = 0，某些驱动或中间件会忽略事务控制指令。
- 安全做法：在过程开头加
SET autocommit = 0;，结尾再SET autocommit = 1;（或交由调用方控制） - 更推荐统一用
START TRANSACTION+COMMIT/ROLLBACK，不依赖autocommit开关 - 注意：MySQL 8.0+ 中，
START TRANSACTION会临时覆盖 autocommit，但前提是它真被执行到了——而它可能被前面的隐式提交提前终结
存储引擎不支持事务（比如表是 MyISAM）
这是最容易被忽略的基础问题：哪怕过程逻辑完美、handler齐全、autocommit关了，只要操作的表用的是MyISAM，ROLLBACK 就是摆设。
- 用
SHOW CREATE TABLE table_name;确认引擎是否为InnoDB -
ALTER TABLE table_name ENGINE = InnoDB;可在线转换（5.6.10+），但大表需评估锁表现 - 新建表时务必显式指定
ENGINE=InnoDB，别依赖默认值（尤其跨版本迁移时）
真正棘手的地方在于：这些因素往往叠加出现。比如一个MyISAM表上跑了带ALTER的存储过程，又没写HANDLER，最后还连在autocommit=1的连接上——这时别说回滚，连“哪里出的问题”都得一层层剥开查。动手前先看SHOW ENGINES;和SHOW VARIABLES LIKE 'autocommit';，比直接改代码更省时间。
