你有没有遇到过这样的情况：转账时手机卡了一下，页面没反应，结果刷新一看——钱扣了，但对方账户没收到？或者电商下单填完地址、付完款，系统突然报错，订单却莫名生成了两笔？这些背后，往往靠的是数据库里的“事务回滚”在悄悄兜底。
事务不是“操作”，而是一组动作的承诺
事务（Transaction）不是某条SQL语句，而是把多个读写操作打包成一个不可分割的逻辑单元。比如银行转账：从A账户减100元，同时给B账户加100元——这两步必须“全成功”或“全不执行”，不能只做一半。这就是常说的ACID特性中的原子性（Atomicity）。
回滚不是删记录，而是“倒带”到上一个快照
真正让回滚能生效的，是数据库在事务开始前悄悄记下的“快照”。以MySQL InnoDB为例，它用的是undo log（回滚日志）：每次修改数据前，先把旧值存进undo log里，并打上事务ID标记。这样，一旦执行到一半出错（比如网络中断、主键冲突、触发器抛异常），数据库就顺着这个日志，把所有已改但未提交的行，逐个恢复成事务开始前的样子。
举个简单例子：
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE user_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE user_id = 2;
-- 这里突然断电或执行了 ROLLBACK;
ROLLBACK;执行ROLLBACK后，InnoDB不会去查原始备份文件，也不会扫描整张表，而是直接翻undo log，找到user_id=1和user_id=2对应的旧balance值，原样写回去——整个过程毫秒级完成。
回滚也有代价，不是万能安全锁
很多人以为“只要加了事务，出错就能自动回滚”，其实不然。比如程序里手动写了COMMIT，但后续代码崩溃了，数据库可不管应用层死没死；又比如用了AUTOCOMMIT=1模式，每条UPDATE都自动提交，那根本没机会回滚。再比如长事务长时间不提交，undo log越积越多，可能撑爆磁盘，甚至拖慢整个库的性能。
更隐蔽的是：某些操作压根不进undo log。像DROP TABLE、TRUNCATE TABLE这类DDL语句，在多数数据库中无法回滚；还有像向外部系统发HTTP请求、写本地文件这类“事务外动作”，数据库完全看不见，自然也救不回来——这就要求开发者在设计时主动补漏，比如用补偿事务或消息队列对账。
安全场景下，回滚常被当“后悔药”用
在安全运维中，回滚机制常被用来应对误操作。比如DBA半夜执行了错误的UPDATE语句，影响了上万条用户数据。如果提前开启了binlog+GTID，并配置了flashback工具，还能基于日志反向生成回滚SQL；但若没开，就只能依赖最近一次的备份+binlog重放——这时，undo log早已被覆盖，真正的“即时回滚”窗口期其实很短。
所以别把回滚当成保险柜。日常开发中，建议：显式写BEGIN/COMMIT、避免长事务、敏感操作前先SELECT FOR UPDATE加锁、对外部调用做好幂等处理——这些比指望“出事再回滚”靠谱得多。