保存点是innodb事务内命名的逻辑锚点，非编程变量，需显式开启事务且仅在当前事务有效；支持在普通sql块中设置、回滚（rollback to）和释放（release），同名会覆盖，commit/rollback后自动清除。

在 MySQL 的 InnoDB 存储引擎中，保存点（SAVEPOINT）不是“变量”意义上的编程变量，而是一个命名的事务内标记点。它不能被赋值、修改或动态拼接，但可以通过命名、回滚和释放进行结构化控制。所谓“普通块”通常指非存储过程/函数的常规 SQL 执行块（如客户端命令行、应用层 JDBC/ORM 中的事务块），这类场景下完全支持 SAVEPOINT 的实战使用。

保存点的本质与适用前提

保存点是事务内部的逻辑锚点，仅在当前事务生命周期内有效。它的核心价值在于：当某步操作出错时，不放弃全部已执行逻辑，只撤销从该点之后的操作。必须满足两个前提：

• 使用 InnoDB 引擎（MyISAM 不支持事务和保存点）
• 显式开启事务（BEGIN 或 START TRANSACTION），且未自动提交（autocommit=0）

在普通 SQL 块中设置并使用保存点

直接在命令行、Navicat、DBeaver 或应用代码中执行以下顺序即可形成可回滚的“普通块”：

• BEGIN; —— 启动事务
• UPDATE t1 SET status='processing' WHERE id=100; —— 成功操作一
• SAVEPOINT sp_after_update1; —— 设置第一个保存点（名称建议语义化）
• INSERT INTO log VALUES (NOW(), 'step2'); —— 成功操作二
• SAVEPOINT sp_after_insert; —— 设置第二个保存点
• DELETE FROM t2 WHERE ref_id=100; —— 可能失败的操作

若 DELETE 报错（如外键约束），可立即执行：ROLLBACK TO sp_after_insert;，此时 INSERT 和 UPDATE 仍保留，DELETE 被撤销。

回滚后继续执行与保存点清理

回滚到保存点后，事务仍处于活跃状态，可继续执行其他语句：

• 执行 ROLLBACK TO sp_after_update1; 后，INSERT 和 DELETE 都被撤销，但 UPDATE 仍在
• 接着可尝试替代操作：UPDATE t2 SET flag=1 WHERE ref_id=100;
• 若确认流程完成，执行 COMMIT; 提交全部保留操作
• 若不再需要某个中间点，可用 RELEASE SAVEPOINT sp_after_insert; 显式释放（非必需，但利于资源清晰）

命名与嵌套使用的注意事项

保存点名是标识符，不是变量，但有实际使用约束：

• 同名保存点会覆盖前一个（SAVEPOINT a; SAVEPOINT a; → 只剩第二个 a）
• 可设多个不同名保存点，回滚到外层点（如 sp1）会自动使内层点（如 sp2）失效
• 事务一旦 COMMIT 或 ROLLBACK，所有保存点自动清除，无需手动释放
• 避免用纯数字或含特殊字符的名字，推荐小写字母+下划线，如 sp_order_created