能，MySQL 的 SAVEPOINT 仅支持回滚到指定保存点之后的操作，不能选择性撤销某条语句；它本质是事务内标记位，ROLLBACK TO SAVEPOINT 丢弃该点后所有变更，不影响之前操作。
MySQL 中 SAVEPOINT 能否真正实现“部分回滚”？
能，但仅限于回滚到某个保存点之后的操作，不能跳过中间步骤或选择性撤销某几条语句。MySQL 的 SAVEPOINT 本质是事务内的标记位，ROLLBACK TO SAVEPOINT 会把该点之后所有变更（包括 DML 和部分 DDL）全部丢弃，但不会影响该点之前已执行的语句。
常见误解是以为可以“撤回某一条 UPDATE”，实际做不到——只要没在它之前设 SAVEPOINT，就只能连带回滚后续所有操作。
怎么正确设置和回滚到 SAVEPOINT？
必须在同一个事务内操作，且 SAVEPOINT 名称在同一事务中不可重复；回滚后，该保存点自动失效，但其之前的保存点仍可用。
-
BEGIN或START TRANSACTION后才能用SAVEPOINT - 设点：
SAVEPOINT sp1;（名称建议带业务含义，如sp_insert_user） - 回滚：
ROLLBACK TO SAVEPOINT sp1;（不是ROLLBACK TO sp1，漏掉SAVEPOINT关键字会报错） - 释放保存点（可选）：
RELEASE SAVEPOINT sp1;，避免事务过长时占用内部资源
示例：
START TRANSACTION;
INSERT INTO orders VALUES (1001, 'A');
SAVEPOINT after_order;
UPDATE accounts SET balance = balance - 100 WHERE user_id = 123;
INSERT INTO logs VALUES ('deduct', NOW());
-- 发现余额不足，只撤回扣款和日志
ROLLBACK TO SAVEPOINT after_order;
COMMIT;
哪些操作会让 SAVEPOINT 失效或行为异常？
不是所有语句都支持被 ROLLBACK TO SAVEPOINT 撤销。遇到以下情况，保存点可能被隐式清除，或回滚无效：
- 执行
DROP TABLE、ALTER TABLE等隐式提交语句后，所有保存点立即失效（MySQL 5.7+ 默认行为） - 触发器内发生的修改无法被外层
ROLLBACK TO SAVEPOINT撤销（除非触发器自己设点并回滚） - 使用
XA START进入 XA 事务模式后，SAVEPOINT不可用 - 在存储过程中调用
ROLLBACK（非TO SAVEPOINT）会清空整个事务，包括所有保存点
错误现象举例：ERROR 1305 (42000): SAVEPOINT sp1 does not exist，往往是因为前面执行了隐式提交语句，或拼错了保存点名。
和应用层重试、补偿逻辑比，SAVEPOINT 适合什么场景？
它只适合“单事务内、顺序依赖强、失败可即时判断”的轻量控制，比如插入主表后立刻插入关联子表，子表失败则放弃子表操作但保留主表记录。
- ✅ 适合：同一事务中多个 DML 步骤，中间某步失败需局部回退（如订单+库存+日志三步，库存不足则只撤库存和日志）
- ❌ 不适合：跨服务调用、需调用外部 API、涉及消息队列投递、或需要异步修复的数据一致性场景
- ⚠️ 注意：高并发下滥用
SAVEPOINT可能延长锁持有时间，特别是对行锁或间隙锁的持续占用
真正复杂的业务逻辑，保存点只是辅助手段，最终还得靠幂等设计和最终一致性保障。
保存点本身不解决死锁或长事务问题，反而可能掩盖事务边界不清的问题——设太多点，不如先拆清业务阶段再决定是否分事务。
