mysql不支持事务嵌套，第二层start transaction会隐式提交第一层；唯一合法替代是savepoint，用于事务内分段回滚，需注意命名唯一、作用域及引擎兼容性。
MySQL不支持真正的事务嵌套，START TRANSACTION 会隐式提交当前事务
你写两层 START TRANSACTION，第二层不会新建嵌套事务，而是先自动提交第一层未提交的变更，再开启新事务。这是最常被误解的点——不是“嵌套失败”，而是“根本没嵌套”。
典型错误现象：ROLLBACK 只回滚最后一层，前面的 INSERT 已经落库；或者执行第二层 START TRANSACTION 后，发现第一条 SELECT 查不到刚插入的数据（因为被隐式提交又隔离了）。
- 唯一合法的“嵌套”替代方案是
SAVEPOINT -
SAVEPOINT不开启新事务，只在当前事务内设标记点 - 每个
SAVEPOINT名必须唯一，重复名会被覆盖（不是报错） - 事务结束（
COMMIT或ROLLBACK）后所有SAVEPOINT自动失效
用 SAVEPOINT 实现逻辑分段回滚：语法与常见误用
比如批量导入用户数据时，想对每个用户的子操作（插入主表 + 关联权限）做独立回滚，但整体仍属一个事务。这时靠 SAVEPOINT 划界最稳妥。
正确写法：
START TRANSACTION;
INSERT INTO users (name) VALUES ('Alice');
SAVEPOINT sp_user_alice;
INSERT INTO permissions (user_id, role) VALUES (LAST_INSERT_ID(), 'admin');
-- 如果这句失败，只回滚权限插入，保留用户记录
ROLLBACK TO SAVEPOINT sp_user_alice;
-- 继续处理下一个用户...
容易踩的坑：
- 忘记在
ROLLBACK TO SAVEPOINT后继续执行后续逻辑，导致整个事务卡住 - 用动态拼接的变量名当
SAVEPOINT名（如sp_@i），MySQL 不支持变量名作为保存点标识 -
RELEASE SAVEPOINT用得过早——它只是删除标记点，不回滚，但删完就无法再ROLLBACK TO该点
存储过程中使用 SAVEPOINT 的兼容性与性能注意点
在 MySQL 5.7+ 存储过程里用 SAVEPOINT 是安全的，但要注意异常处理器（DECLARE HANDLER）和 SAVEPOINT 的配合顺序。
关键约束：
-
SAVEPOINT必须在DECLARE HANDLER之后声明，否则 handler 捕获异常时可能找不到对应保存点 - 每次
SAVEPOINT都有轻微开销，高频小事务中（如每秒上千次）不建议每行都设，按业务逻辑块粒度设更合理 - MyISAM 表不支持事务，用了
SAVEPOINT也不会生效，检查引擎类型比查文档更快：SHOW CREATE TABLE users;
ROLLBACK TO SAVEPOINT 失败的三种典型错误信息
不是所有报错都意味着语法错，得看上下文：
-
ERROR 1305 (42000): SAVEPOINT sp_x does not exist：保存点名拼错，或已被RELEASE/ 事务结束清除 -
ERROR 1196 (HY000): Some non-transactional changed tables couldn't be rolled back：混用了 MyISAM 表或临时表，回滚只能作用于 InnoDB -
ERROR 1300 (HY000): Invalid utf8mb4 character string：看似无关，实则是之前某条语句因字符集问题触发隐式提交，导致后续SAVEPOINT不在活跃事务中
真正难调试的是第三种——它不直接抱怨 SAVEPOINT，而是让你以为是字符问题，结果根因是事务状态已丢失。遇到这种，先查 SELECT @@in_transaction; 确认是否还在事务里。
