能，MySQL通过SAVEPOINT在显式事务中实现局部回滚：需先START TRANSACTION，再设点并ROLLBACK TO SAVEPOINT；DDL会隐式提交致保存点失效，命名重复则覆盖，非事务模式下保存点无效。
MySQL 事务中 SAVEPOINT 的基本用法
MySQL 支持在事务内设置保存点，用于实现局部回滚，而不是整个事务回滚。关键前提是：必须在 BEGIN 或 START TRANSACTION 后、COMMIT/ROLLBACK 前使用，且当前连接未断开。
保存点名是用户自定义标识符，区分大小写，建议用有意义的短名（如 sp_insert_user），避免空格或特殊字符。
-
SAVEPOINT sp_name创建保存点 -
ROLLBACK TO SAVEPOINT sp_name回滚到该点（不会结束事务） -
RELEASE SAVEPOINT sp_name删除保存点（释放资源，不影响数据）
为什么 ROLLBACK TO SAVEPOINT 后还能继续执行？
因为 ROLLBACK TO SAVEPOINT 只撤销该点之后的语句，事务仍处于活跃状态，可以继续插入、更新或再设新保存点。这点和全量 ROLLBACK 有本质区别——后者直接退出事务。
常见误判：执行 ROLLBACK TO SAVEPOINT sp1 后立刻 COMMIT，结果发现之前被回滚的操作没生效，但其他未回滚部分却提交了——这正是预期行为，不是 bug。
- 事务状态在
ROLLBACK TO SAVEPOINT后仍是ACTIVE，可通过SELECT @@in_transaction验证 - 若想终止整个事务，仍需显式
ROLLBACK或COMMIT - 重复使用同一保存点名会覆盖前一个（MySQL 允许，但易引发逻辑混乱，建议避免）
遇到 ERROR 1305 (42000): SAVEPOINT sp_name does not exist 怎么办？
这个错误通常不是语法问题，而是保存点已被释放、事务已提交/回滚，或跨连接误操作。MySQL 的保存点作用域仅限当前事务、当前连接。
- 检查是否误用了
RELEASE SAVEPOINT sp_name后又尝试ROLLBACK TO它 - 确认没有在存储过程中隐式提交（比如执行了
CREATE TABLE等 DDL，会自动提交当前事务） - 应用层使用连接池时，要确保同一个逻辑事务不被分配到不同物理连接上
- 调试时可用
SHOW ENGINE INNODB STATUS\G查看当前事务状态和保存点信息（需 SUPER 权限）
嵌套保存点与性能影响要注意什么？
MySQL 不支持真正意义上的嵌套事务，但可以链式设置多个保存点（sp1 → sp2 → sp3），然后选择性回滚到任一中间点。不过每多一个保存点，InnoDB 就要额外维护一条 undo log 记录和内存结构。
高并发写入场景下，频繁建/删保存点可能轻微增加锁竞争和日志刷盘压力。一般业务中几十个保存点无感，但若在循环里动态生成（如 SAVEPOINT sp_i 在 for 循环中），就容易触发 ERROR 1196 (HY000): Some non-transactional changed tables couldn't be rolled back 或内存溢出。
- 避免在大事务中无节制创建保存点；优先用应用层逻辑控制分支，而非依赖大量
ROLLBACK TO -
RELEASE SAVEPOINT不是必须的，但显式释放可减少事务元数据占用 - 注意：DDL 操作（如
ALTER TABLE）会导致隐式提交，所有保存点立即失效
SELECT 校验中间状态。 
