mysql不支持事务嵌套，重复begin被忽略，仅存在单层事务；需用savepoint实现局部回滚，配合rollback to savepoint和release savepoint管理回退点。
MySQL 里 BEGIN 嵌套不生效，为什么？
MySQL 不支持真正的事务嵌套。你写两个 BEGIN，第二个不会开启新事务，而是被忽略——当前会话仍处于第一个事务中。这和 PostgreSQL 或 SQL Server 的行为完全不同，容易误以为“内层事务能独立提交/回滚”。
-
BEGIN、START TRANSACTION都只是标记事务起点，重复调用无意义 - 没有
COMMIT或ROLLBACK之前，所有操作都在同一个事务上下文中 - 如果你在存储过程中反复写
BEGIN，实际只有一层事务控制流
真正需要“局部回滚”时，得靠 SAVEPOINT，而不是幻想嵌套事务。
用 SAVEPOINT 实现局部回滚的正确姿势
SAVEPOINT 是 MySQL 提供的轻量级回滚锚点，它不开启新事务，但允许你在同一事务内定义多个可回退位置。
- 先执行正常 DML（如
INSERT、UPDATE） - 中间设一个保存点：
SAVEPOINT sp1 - 后续操作出错时，用
ROLLBACK TO SAVEPOINT sp1撤销从该点之后的所有更改 - 注意：不能
COMMIT到某个 savepoint，只能整个事务COMMIT或全部ROLLBACK
START TRANSACTION;
INSERT INTO users(name) VALUES('alice');
SAVEPOINT after_alice;
INSERT INTO users(name) VALUES('bob');
-- 出错了，只撤掉 bob
ROLLBACK TO SAVEPOINT after_alice;
COMMIT;这个过程里，alice 保留，bob 被丢弃，且事务仍处于活跃状态，可继续操作。
RELEASE SAVEPOINT 什么时候该用？
SAVEPOINT 会一直存在直到事务结束，或被显式释放。不释放也不会报错，但可能带来两个隐性问题：
大量 savepoint 占用少量内存（通常可忽略，但在长事务 + 高频设点场景下有累积效应）
同名 savepoint 被重复定义时，旧的自动被覆盖，容易误判回滚范围
显式释放用：
RELEASE SAVEPOINT sp1只在确定后续不会再回滚到该点时才释放，比如已成功提交了依赖它的逻辑分支
存储过程中若用循环 + savepoint，建议每次迭代后
RELEASE，避免名字冲突或残留
别为了“整洁”提前释放——万一中间加了新逻辑要回滚，就找不回那个点了。
应用层调用时，SAVEPOINT 容易漏掉的边界情况
ORM（如 Django、SQLAlchemy）或数据库连接池对 SAVEPOINT 支持不一，很多默认不透出底层 savepoint 控制权。
- Django 的
transaction.atomic()嵌套其实是用 savepoint 模拟的，但仅限于同一数据库连接；跨连接或手动游标操作会失效 - SQLAlchemy 的
connection.begin_nested()底层就是SAVEPOINT，但它要求 driver 支持（MySQL Connector/Python ≥ 8.0.23 才稳定） - 如果用了连接池（如 PooledDB），事务状态不跨连接传递，
SAVEPOINT只在当前连接有效，换连接就没了
最常被忽略的是：事务没显式 COMMIT 或 ROLLBACK，连接归还池后，savepoint 还在，但没人能访问它——不是 bug，是设计如此。这种“幽灵 savepoint”不会影响新连接，但会让调试时误以为状态残留。
