Savepoint是MySQL中用于事务内局部回滚的标记点，语法为SAVEPOINT sp_name和ROLLBACK TO SAVEPOINT sp_name，仅在显式开启的事务中有效，不支持跨连接或自动提交模式，命名重复会覆盖，回滚后后续Savepoint自动失效。
MySQL中Savepoint的基本用法和语法结构
Savepoint不是独立事务，而是嵌套在当前事务中的标记点，用于局部回滚。它只在当前事务生命周期内有效，事务提交或回滚后所有Savepoint自动失效。
关键语法只有两条：SAVEPOINT sp_name 和 ROLLBACK TO SAVEPOINT sp_name。注意不能对已释放（RELEASE SAVEPOINT）或不存在的Savepoint执行回滚，否则报错：ERROR 1305 (42000): SAVEPOINT sp_name does not exist。
-
sp_name必须是合法标识符，不支持变量或表达式，例如不能写SAVEPOINT CONCAT('sp_', @i) - 同一个事务中可定义多个Savepoint，名字重复会覆盖前一个（MySQL 8.0+ 报警告，5.7 直接覆盖）
- 执行
ROLLBACK TO SAVEPOINT不会结束事务，后续仍可继续执行 SQL 或再设 Savepoint
什么时候该用Savepoint而不是直接回滚整个事务？
典型场景是批量操作中部分失败需保留前面成功步骤，比如导入用户数据时校验失败但不希望丢弃已插入的合法记录。此时 Savepoint 比“全量重试 + 幂等逻辑”更轻量。
但要注意：Savepoint 无法跨连接生效，也不能绕过锁等待——如果 ROLLBACK TO SAVEPOINT 前有行锁未释放（如 UPDATE 未提交），回滚后锁依然持有，可能阻塞其他事务。
- 适合：单连接内、逻辑分段清晰、各段间无强依赖的 DML 操作（如先插主表再插子表，子表某条失败时回滚子表部分）
- 不适合：需要跨多个业务模块协调、或涉及外部系统调用（如发消息、写文件）的场景——Savepoint 只管 MySQL 内部状态
- 替代方案考虑：应用层捕获异常后手动构造反向 SQL（如 INSERT 对应 DELETE），比依赖 Savepoint 更可控
常见错误：Savepoint 在自动提交模式下无效
如果没显式开启事务（即 AUTOCOMMIT=1），每条语句都是独立事务，SAVEPOINT 虽不报错，但紧接着的 ROLLBACK TO SAVEPOINT 会提示 ERROR 1305 (42000): SAVEPOINT sp1 does not exist，因为上一条语句已自动提交，Savepoint 随之消失。
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
验证方式：SELECT @@autocommit; 返回 1 表示开启，必须先执行 START TRANSACTION 或 SET autocommit = 0。
- PHP PDO 中默认开启 autocommit，需调用
$pdo->beginTransaction()才能用 Savepoint - Java JDBC 同理，
connection.setAutoCommit(false)是前置条件 - MySQL CLI 默认 autocommit=1，务必记得先输入
BEGIN;
嵌套 Savepoint 的行为和陷阱
MySQL 不支持真正意义上的嵌套事务，但允许在已有 Savepoint 后再设新 Savepoint，形成层级关系。例如：
START TRANSACTION; INSERT INTO t VALUES (1); SAVEPOINT sp1; INSERT INTO t VALUES (2); SAVEPOINT sp2; INSERT INTO t VALUES (3); ROLLBACK TO SAVEPOINT sp1; -- 此时只剩值 1
执行 ROLLBACK TO SAVEPOINT sp1 后，sp2 自动失效（MySQL 会清理所有在其之后定义的 Savepoint），再次执行 ROLLBACK TO SAVEPOINT sp2 必报错。
- Savepoint 名字只是标签，没有作用域概念，命名冲突会导致预期外覆盖
- 不建议动态生成 Savepoint 名（如拼接时间戳），容易因并发导致名字重复或难以调试
- 高并发写入时慎用大量 Savepoint，每个 Savepoint 会增加事务内部状态开销，极端情况下影响性能
Savepoint 看似灵活，但它的“局部性”完全依赖开发者对事务边界的准确控制——一旦忘记 START TRANSACTION 或误判哪段该设点，回滚就变成盲操作。
