必须配START TRANSACTION才能回滚，因MySQL默认autocommit=1，每条语句独立提交；不显式开启事务，ROLLBACK无作用。EXIT HANDLER需在内部执行ROLLBACK并常配RESIGNAL，CONTINUE HANDLER则依赖变量判断后手动回滚。
MySQL存储过程里DECLARE HANDLER必须配START TRANSACTION才能回滚
不加 START TRANSACTION，哪怕写了 DECLARE EXIT HANDLER FOR SQLEXCEPTION，出错也不会自动回滚。MySQL默认是自动提交模式（autocommit=1），每条语句单独成事务，ROLLBACK 无事务可滚——这是最常被忽略的前提。
- 必须在
HANDLER块外、COMMIT前显式写START TRANSACTION - 不要用
BEGIN替代START TRANSACTION，MySQL会把它解析为BEGIN ... END语句块，不是事务起始 - 如果过程里调用了其他也含事务的存储过程，嵌套事务不生效：内层
COMMIT会提前提交外层整个事务，导致外层后续ROLLBACK失效
EXIT HANDLER 和 CONTINUE HANDLER 的行为差异直接影响回滚时机
EXIT HANDLER 一捕获异常就跳出当前 BEGIN ... END 块，适合“出错即停、立刻回滚”的场景；CONTINUE HANDLER 则只设标志位、继续往下执行，需手动判断并 ROLLBACK。
- 用
EXIT HANDLER时，ROLLBACK必须写在 handler 内部，且通常紧跟BEGIN后，否则 handler 执行完就退出，后续语句（包括COMMIT）不会运行 - 用
CONTINUE HANDLER时，常见写法是声明变量如t_error INT DEFAULT 0，handler 里SET t_error = 1，之后靠IF t_error = 1 THEN ROLLBACK; ELSE COMMIT; END IF;控制流向 - 错误类型要选准：
SQLEXCEPTION捕获错误（如主键冲突、列不存在），SQLWARNING捕获警告（如截断、隐式类型转换），二者可分别定义 handler
RESIGNAL 或自定义返回值，决定调用方能否感知失败
只在 handler 里 ROLLBACK 不够，调用方可能收不到任何报错，还以为操作成功了。
- 加
RESIGNAL可原样抛出原始错误（含错误码、消息），但要求 MySQL ≥ 5.7.2；低于该版本会报语法错误 - 更兼容的做法是用
OUT参数返回状态码，比如OUT p_return_code TINYINT，出错设为1，成功为0，调用时用CALL proc(@ret); SELECT @ret;检查 - 不要在 handler 里只设变量、不
ROLLBACK，也不要在没事务上下文时调ROLLBACK（会报ERROR 1305 (42000): SAVEPOINT does not exist类似提示）
嵌套调用时事务控制权实际在最外层过程
如果过程 A 调用过程 B，而 B 自己写了 START TRANSACTION 和 COMMIT，那 A 的事务边界就被破坏了——B 的 COMMIT 会把 A 开启的事务一起提交掉。
- 所有子过程应避免自行开启/提交事务，只做 DML 操作，由最外层统一管控
- 若必须复用带事务的子过程，应改造成不带事务的纯逻辑封装，并在外层统一加
START TRANSACTION/ROLLBACK/COMMIT -
SAVEPOINT在存储过程中可用，但 handler 无法直接跳转到某个 savepoint，只能全量ROLLBACK或配合应用层逻辑手动ROLLBACK TO SAVEPOINT
真正容易被绕晕的点是：handler 本身不启动事务，也不保证原子性；它只是个错误响应开关。回滚是否发生、回滚到哪一步、调用方是否知情——全取决于你有没有在正确位置写对组合：START TRANSACTION + 合适的 HANDLER 类型 + 显式 ROLLBACK + 状态透出机制。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
