SAVEPOINT必须在事务内显式声明，命名需为合法标识符（如sp_order_create），不可含空格、特殊符号或保留字，重复命名会静默覆盖；ROLLBACK TO SAVEPOINT仅撤销之后更改，事务仍活跃。
SAVEPOINT 语法写在哪、怎么命名才安全
保存点不是独立语句，必须在事务内用 SAVEPOINT 命令显式声明，且名字不能含空格、特殊符号或保留字。常见错误是用变量名或动态生成的字符串直接拼接，结果触发语法错误或意外覆盖。
-
SAVEPOINT后面只能跟一个合法标识符（如sp_user_insert），不能加引号，也不能是数字开头 - 同一个事务中重复使用相同名字的
SAVEPOINT，会隐式覆盖前一个——这不是报错，而是静默替换，容易误判回滚范围 - 名字建议带上下文前缀（比如操作模块 + 动作），避免在嵌套逻辑里冲突，例如
sp_order_create比sp1更可靠
ROLLBACK TO SAVEPOINT 执行后事务状态还正常吗
执行 ROLLBACK TO SAVEPOINT 只撤销该保存点之后的更改，事务仍处于活动状态，可以继续执行其他 SQL 或再设新保存点。但要注意：被回滚掉的行级锁通常会释放，而表级锁（如 LOCK TABLES）行为因数据库而异，MySQL InnoDB 下不会自动释放显式加的表锁。
- 回滚到保存点后，
COMMIT仍可提交之前未被回滚的部分；ROLLBACK（无目标）则彻底放弃整个事务 - PostgreSQL 允许在保存点内再建保存点，MySQL 不支持嵌套保存点（第二次
SAVEPOINT会覆盖前一个） - 如果在保存点之后执行了 DDL（如
ALTER TABLE），MySQL 会自动提交当前事务，导致保存点失效——这是最容易踩的坑
不同数据库对 SAVEPOINT 的兼容性差异
核心语法一致，但行为边界差别大。最常出问题的是自动提交场景和 DDL 交互逻辑。
- MySQL：遇到
CREATE/DROP/ALTER会隐式提交事务，所有保存点立即失效；开启autocommit=0也拦不住 - PostgreSQL：DDL 在事务内合法，保存点可跨 DDL 存在；但
TRUNCATE会释放部分保存点相关资源，不推荐混用 - SQLite：支持
SAVEPOINT，但不支持命名释放（只能用RELEASE SAVEPOINT，不能ROLLBACK TO后再RELEASE）；且不支持在WITHOUT ROWID表上做某些回滚操作
为什么有时候 ROLLBACK TO SAVEPOINT 没效果
表面执行成功，但数据没变回去，大概率是保存点本身已失效，或者回滚目标根本没覆盖到修改语句。
- 检查是否在保存点之后执行过任何隐式提交操作：除了 DDL，还有
SELECT ... FOR UPDATE在某些隔离级别下可能触发锁升级，间接影响保存点有效性 - 确认修改语句确实在保存点之后执行——比如把
INSERT写在SAVEPOINT前，那回滚当然无效 - 某些 ORM（如 Django 的
transaction.atomic()嵌套块）会自动管理保存点，手动调ROLLBACK TO可能被拦截或忽略，优先用框架提供的回滚接口
