rollback 无效的根本原因是事务状态已不可回滚，如 autocommit=1、未显式开启事务或隐式提交语句触发提交；commit 后无法原生撤回，仅能依赖备份恢复或应用层补偿。
事务回滚失败时，ROLLBACK 为什么没起作用？
常见现象是执行了 ROLLBACK 却发现数据还是被提交了，或者提示 SAVEPOINT does not exist。根本原因往往不是命令写错，而是事务状态已不可回滚——比如当前连接已自动提交、处于隐式提交模式，或上一条语句触发了隐式提交（如 CREATE TABLE、ALTER TABLE）。
- MySQL 默认开启
autocommit=1，单条 DML 语句会立即提交，ROLLBACK无效 - PostgreSQL 要求显式
BEGIN或START TRANSACTION后才能回滚，否则报错ERROR: no transaction in progress - SQLite 在没有
BEGIN时也允许ROLLBACK，但实际什么也不做，不报错也不警告
示例：MySQL 中误以为开启了事务
UPDATE users SET name = 'Alice' WHERE id = 1;<br>ROLLBACK; -- 这行完全没效果，因为 autocommit=1 下 UPDATE 已落地 COMMIT 执行后还能恢复吗？
不能。一旦 COMMIT 成功返回，ACID 的持久性（Durability）就生效了——数据已写入磁盘（或 WAL 日志并刷盘），数据库不提供内置的“反向提交”机制。
- 某些数据库（如 PostgreSQL）支持时间点恢复（PITR），但依赖外部备份 + WAL 归档，不是事务级回退
- MySQL 的 binlog 可用于逻辑恢复，但需提前开启
binlog_format=ROW，且恢复操作是手动重放或工具解析，非原子回退 - 任何“事务已提交还能撤回”的方案，本质都是应用层补偿（比如插入逆向记录），不是数据库原生能力
所以别在生产环境靠 COMMIT 后补救，而要在 COMMIT 前用 SELECT …… FOR UPDATE 或 SAVEPOINT 控制粒度。
隔离级别怎么选？READ COMMITTED 和 REPEATABLE READ 差在哪？
差别不在“能不能读到新数据”，而在“同一事务内多次读是否一致”以及“幻读是否被阻止”。
-
READ COMMITTED：每次SELECT都读最新已提交版本，可能遇到不可重复读（两次查同一行，值不同）和幻读（两次查同一范围，行数不同） -
REPEATABLE READ（MySQL InnoDB 默认）：事务启动时拍快照，后续读都基于该快照，解决不可重复读，但 不完全阻止幻读（仅通过间隙锁防止 INSERT 幻影，UPDATE/DELETE 仍可能看到新插入行） -
SERIALIZABLE：加范围锁或使用串行调度，彻底避免幻读，但并发性能明显下降，容易锁等待
注意：PostgreSQL 的 REPEATABLE READ 实现更严格，能真正避免幻读；MySQL 的同名级别行为不同，别直接套用经验。
为什么 SELECT 也会被锁？明明没写数据
因为隔离级别和执行计划决定了是否加锁。默认情况下，SELECT 是快照读（不加锁），但以下情况会升级为当前读并加锁：
- 显式加锁子句：
SELECT …… FOR UPDATE、SELECT …… LOCK IN SHARE MODE - 在
REPEATABLE READ下执行UPDATE或DELETE前，会先用当前读定位记录，此时隐式触发锁 - 索引失效导致全表扫描，即使只是
SELECT …… FOR UPDATE，也可能锁住所有行甚至整个聚簇索引
常见坑：
- 应用里写了个
SELECT id FROM orders WHERE status = 'pending' LIMIT 1 FOR UPDATE，但status没索引 → 锁全表 → 其他订单操作全阻塞 - 使用
READ COMMITTED时，SELECT …… FOR UPDATE只锁命中的行；换成REPEATABLE READ，InnoDB 可能锁住间隙（GAP Lock），影响并发插入
事务不是黑盒，它的行为由隔离级别、SQL 类型、索引结构、存储引擎共同决定。最容易被忽略的是：同一个 SQL，在不同数据库、不同配置、不同执行路径下，锁行为和可见性可能天差地别。
