事务中途出错时，用 SAVEPOINT 可实现局部回滚：先设保存点 SAVEPOINT sp1，出错后执行 ROLLBACK TO SAVEPOINT sp1，仅撤回其后操作，sp1 前的仍生效；需注意命名覆盖、DDL 隐式提交及存储过程中的动态 SQL 限制。
事务中途出错时，怎么只回滚一部分而不是整个事务
靠 SAVEPOINT。MySQL 不支持部分回滚（partial rollback）的语法糖，但用保存点能手动切分事务逻辑段，让错误只影响局部。
常见错误现象：在存储过程里执行一连串 INSERT/UPDATE，中间某条报错（比如违反唯一约束），结果 ROLLBACK 把前面成功的也都撤了——这不是你想要的。
使用场景：批量导入带校验的数据、多步骤状态更新（如“下单→扣库存→生成发票”）、补偿式业务逻辑。
- 先用
SAVEPOINT sp1标记一个位置，后续可退回到这里 - 出错后执行
ROLLBACK TO SAVEPOINT sp1，不会影响sp1之前的操作 - 记得用
RELEASE SAVEPOINT sp1清理不用的保存点，否则可能耗尽会话资源 - 保存点是会话级的，不能跨连接共享；也不受外部事务控制（比如嵌套事务不存在，只是模拟）
保存点命名和重复定义会怎样
名字只是标识符，不强制唯一，但重复定义会覆盖前一个同名保存点——不是报错，而是静默替换。
容易踩的坑：在循环里反复用固定名建保存点（比如 SAVEPOINT loop_step），结果每次都在改同一个锚点，ROLLBACK TO SAVEPOINT loop_step 实际回滚到最近一次定义的位置，不是你“以为”的那一轮。
- 动态命名更安全，比如拼上循环变量：
SAVEPOINT sp_loop_i - 名字长度上限是 64 字符，超长会被截断，建议保持简短清晰
- 大小写不敏感，
SP1和sp1视为同一保存点
保存点 + 自动提交关掉的情况下，事务边界怎么算
保存点本身不开启或结束事务，它完全依附于当前事务生命周期。只要没执行 COMMIT 或显式 ROLLBACK，所有保存点都有效。
性能影响很小：保存点本质是 InnoDB 在事务结构体里记了个 undo log 的偏移位置，开销几乎可忽略。
- 如果 autocommit=OFF，一条
INSERT就已进入事务，此时建保存点合法 - 如果 autocommit=ON，每个语句自带事务，
SAVEPOINT只在该语句内有效，下条语句开始就是新事务——这种模式下保存点基本没意义 - DDL 语句（如
ALTER TABLE）会隐式触发COMMIT，导致所有保存点失效，这点极易被忽略
存储过程中用保存点要注意什么
MySQL 存储过程里可以正常用 SAVEPOINT，但异常处理机制和保存点配合时逻辑容易绕晕。
典型陷阱：在 DECLARE EXIT HANDLER 里执行 ROLLBACK TO SAVEPOINT 后没再做 COMMIT 或继续处理，结果整个过程退出时事务仍处于活动状态，连接空悬着。
- 务必检查 handler 里的恢复路径是否完整：回滚到保存点 → 修正数据或跳过 → 继续执行或显式
COMMIT - 不要在 handler 里写
ROLLBACK（全滚），除非你真想放弃全部 - 保存点名不能用变量直接拼接（
SAVEPOINT @sp_name会报错），得用动态 SQL：SET @sql = CONCAT('SAVEPOINT sp_', i); PREPARE stmt FROM @sql; EXECUTE stmt;
