savepoint是事务内标记点，非独立事务；须在autocommit=0的显式事务中使用，rollback to仅撤销该点之后操作，事务仍活跃可继续commit，同名保存点会静默覆盖。
SAVEPOINT 语法和基本用法
MySQL 的 SAVEPOINT 不是独立事务，而是嵌套在当前事务中的标记点，用于限定 ROLLBACK TO SAVEPOINT 的回滚范围。它只对当前连接、当前未提交的事务有效，事务一提交或回滚，所有保存点自动失效。
基本流程是：BEGIN 或 START TRANSACTION 开启事务 → 执行若干语句 → 插入一个 SAVEPOINT sp1 → 继续执行 → 出错时用 ROLLBACK TO SAVEPOINT sp1 撤销之后的操作，保留之前的部分。
注意：SAVEPOINT 名字区分大小写（取决于系统变量 lower_case_table_names），建议全小写避免歧义；重复定义同名保存点会覆盖前一个，不会报错。
ROLLBACK TO SAVEPOINT 后还能继续提交吗
可以。执行 ROLLBACK TO SAVEPOINT sp1 只撤销该保存点之后的变更，事务仍处于活跃状态，后续语句可正常执行，最终仍可用 COMMIT 提交剩余部分。
但要注意：回滚到保存点后，该保存点及其之后定义的所有保存点都会被删除（比如你有 sp1 → sp2 → sp3，回滚到 sp2 后，sp3 就不存在了）。
常见误操作：
- 回滚到保存点后又试图
ROLLBACK TO SAVEPOINT sp3—— 报错ERROR 1305 (42000): SAVEPOINT sp3 does not exist - 忘记事务还在进行中，直接断开连接或执行
COMMIT，导致意外提交中间状态
与 AUTOCOMMIT=0 和显式事务的配合要点
SAVEPOINT 必须在显式事务中使用，即 AUTOCOMMIT=0 或已执行 START TRANSACTION。如果 AUTOCOMMIT=1，每条语句自动提交，SAVEPOINT 定义后立刻失效，ROLLBACK TO 会报错 ERROR 1305 (42000): SAVEPOINT identifier does not exist。
实操建议：
- 始终用
SELECT @@autocommit;确认当前会话模式 - 在业务逻辑入口显式加
START TRANSACTION，而非依赖连接池默认设置 - 避免在存储过程中混用
START TRANSACTION和SAVEPOINT—— MySQL 不允许在已有活动事务内再执行START TRANSACTION，会隐式提交前序事务
实际场景示例：批量插入中跳过单条失败记录
比如向 orders 表插入多笔订单，其中某条因外键约束失败，你不想整批丢弃，只希望跳过这一条。
START TRANSACTION; INSERT INTO orders (id, user_id) VALUES (1001, 101); SAVEPOINT order_1001; <p>INSERT INTO orders (id, user_id) VALUES (1002, 999); -- 假设 user_id=999 不存在，触发外键错误 -- 此时不执行 ROLLBACK，而是： ROLLBACK TO SAVEPOINT order_1001;</p><p>INSERT INTO orders (id, user_id) VALUES (1003, 102); -- 继续插入下一条 COMMIT;</p>
这样最终提交了 1001 和 1003，跳过了 1002。关键点在于：错误发生后不能靠异常捕获自动回滚，必须由应用层主动判断并执行 ROLLBACK TO SAVEPOINT；MySQL 自身不会“智能跳过”失败语句。
真正容易被忽略的是：保存点无法跨越语句错误恢复 DML 的副作用。例如 INSERT ... ON DUPLICATE KEY UPDATE 已触发更新，再回滚到之前保存点，那个更新也会被撤回——保存点回滚是原子性的，不区分“插入”或“更新”动作。
