MySQL 5.7存储过程无try-catch，必须用DECLARE EXIT HANDLER FOR SQLEXCEPTION配ROLLBACK和RESIGNAL实现错误回滚；嵌套事务不支持，DDL会隐式提交，需确保autocommit=0且事务活跃。
MySQL 5.7存储过程不支持try-catch，必须用DECLARE HANDLER
直接写try或catch会报错ERROR 1064 (42000)——MySQL服务端根本不识别这两个关键字。所谓“自动回滚”，本质是靠DECLARE HANDLER捕获异常后，显式执行ROLLBACK并退出当前逻辑块。它不是语法糖，而是唯一合法的错误响应机制。
必须用DECLARE EXIT HANDLER FOR SQLEXCEPTION配ROLLBACK
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION会导致异常后继续往下走，若没加IF t_error = 1 THEN ROLLBACK; END IF;判断，事务就悬在那儿：既没提交也没回滚，可能锁表、阻塞其他连接。
-
DECLARE EXIT HANDLER FOR SQLEXCEPTION一触发就跳出当前BEGIN ... END块，能确保ROLLBACK一定被执行 - 必须跟
ROLLBACK一起写，handler本身不会自动回滚 - 建议加上
RESIGNAL，否则调用方收不到错误信息，只看到空结果或默认返回值
正确结构示例：
DELIMITER $$
CREATE PROCEDURE safe_transfer()
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
ROLLBACK;
RESIGNAL;
END;
<p>START TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
END$$
DELIMITER ;嵌套调用时事务会被提前提交，回滚失效
MySQL不支持嵌套事务。如果A过程调用B过程，而B内部写了START TRANSACTION和COMMIT，那么B的COMMIT会把A整个事务提前提交掉——A后续即使出错，ROLLBACK也无事务可滚。
- 所有业务逻辑应尽量扁平化，避免在被调用过程中开启/提交事务
- 若必须复用逻辑，被调用过程应声明为“无事务”模式（即不写
START TRANSACTION），由最外层统一控制 - DDL语句（如
CREATE TEMPORARY TABLE）也会隐式提交当前事务，这类操作不能放在需要回滚的事务块里
回滚前务必确认事务活跃且autocommit=0
执行ROLLBACK前，先查SELECT @@in_transaction;是否为1，再查SELECT @@autocommit;是否为0。否则容易出现“执行了ROLLBACK却没效果”的假象。
- autocommit=1时，每条语句自成事务，
ROLLBACK会报“No transaction in progress” - 已执行过
COMMIT的事务不可逆，ROLLBACK无效 - 死锁或锁超时（
innodb_lock_wait_timeout）会自动回滚，但这是InnoDB层行为，不经过你的handler，也无法被RESIGNAL捕获
事务真正可靠的自动回滚，只发生在三件事同时成立时：用了EXIT HANDLER、显式写了ROLLBACK、且整个调用链没有隐式提交点。任何一处漏掉，都可能让数据停留在中间状态。
