MySQL 事务是什么？COMMIT、ROLLBACK 和数据一致性基础

在MySQL应用开发中，只要一个业务动作涉及多个数据库修改，事务几乎就是绕不开的基础机制。创建订单可能同时涉及订单表、库存表、账户表和支付状态；银行转账需要同时修改转出账户和转入账户。如果这些操作之间没有明确的事务边界，一旦程序在中途崩溃、数据库连接断开或者某条SQL执行失败，就可能留下部分已经修改、部分尚未修改的数据。

事务的核心价值，就是把一组数据库操作组织成一个具有明确边界的工作单元。事务成功完成后执行COMMIT，使修改正式提交；如果业务决定放弃本次操作，则执行ROLLBACK撤销当前事务中尚未提交的修改。需要特别注意，数据库并不会因为任意一条SQL报错就自动替开发者完成业务层面的回滚。应用程序必须正确处理异常和事务状态，数据库框架也必须正确配置事务管理。

事务最经典的概念是ACID。原子性（Atomicity）强调一个事务中的修改具有整体性；一致性（Consistency）要求事务执行前后，数据库仍然满足约束和业务规则；隔离性（Isolation）描述并发事务之间的可见性和相互影响；持久性（Durability）则意味着已经成功提交的数据，在符合存储系统和数据库恢复机制的条件下不会因为普通的数据库进程崩溃而丢失。

其中最容易理解的是原子性。假设账户A向账户B转账100元，业务可能需要执行两次余额更新。如果A已经扣款，而B没有成功增加余额，整个业务就出现了严重的数据错误。正确的实现应该把相关操作放在同一个事务中，让它们共享同一个提交点。只要事务没有COMMIT，应用就可以根据执行结果决定是否ROLLBACK。

例如，一个简化的业务可以写成：

START TRANSACTION;

UPDATE users
SET balance = balance - 100
WHERE id = 1
AND balance >= 100;

UPDATE orders
SET status = 'paid'
WHERE order_id = 'ORD123'
AND status = 'pending';

COMMIT;

但真正的生产代码不能仅仅把COMMIT放在最后。应用程序还必须检查每条关键SQL的执行结果，并在任何不可恢复的错误发生后执行ROLLBACK。更重要的是，余额扣减是否成功不能只看SQL有没有报错。上面的UPDATE即使执行成功，也可能因为balance >= 100条件不满足而影响0行。数据库没有报错，但业务实际上没有完成扣款，因此应用层必须检查受影响行数。

典型的应用逻辑实际上更接近“开始事务、执行并验证每一步、出现异常立即回滚、全部成功才提交”。这也是事务编程中经常被忽略的一点：数据库的SQL成功，不等于业务操作成功。

COMMIT和ROLLBACK分别承担两个不同方向的控制作用。COMMIT确认当前事务的修改，使其成为数据库状态的一部分；ROLLBACK则放弃当前事务中尚未提交的修改。事务中的修改通常不会在每一条UPDATE之后都立即成为其他事务可以按照正常隔离规则读取的最终状态，因此事务边界直接决定了业务操作的完整范围。

事务也并不意味着“所有错误都可以撤销”。如果程序已经向第三方支付平台发送了支付请求，然后数据库事务ROLLBACK，第三方系统不会因为你的数据库回滚而自动把支付请求撤销。因此，涉及外部API、消息队列、邮件、文件系统等非数据库资源时，不能把它们简单塞进一个数据库事务就认为整个业务具备原子性。

这也是为什么复杂系统经常需要Transactional Outbox等模式。业务数据库中的关键状态变化和待发送事件先通过数据库事务保证一致，然后由独立的消息投递机制把事件发送出去。这样可以减少“数据库已经提交，但消息没有发出去”或者“消息发出去了，但数据库事务最终回滚”这类问题。

MySQL的事务一致性还与InnoDB存储引擎的日志、锁和MVCC机制密切相关。Redo Log主要用于保障InnoDB的崩溃恢复能力。当数据库发生异常关闭时，InnoDB可以利用相关日志恢复已经提交但数据页尚未完全写入磁盘的数据变化。因此，Redo Log是InnoDB持久性和崩溃恢复体系的重要组成部分，但不能简单理解为“事务日志记录了所有事务操作，所以数据就不会出错”。

并发控制则主要涉及锁和MVCC。InnoDB支持行级锁以及其他类型的锁机制，在修改数据、执行特定范围查询和维护索引一致性时，锁会影响不同事务之间的并发行为。所谓行级锁也不是给某一行永久上锁，而是与具体SQL、索引访问路径、事务隔离级别以及锁类型有关。没有正确使用索引的UPDATE或DELETE甚至可能锁住远超开发者预期的数据范围。

MVCC，即多版本并发控制（Multi-Version Concurrency Control），则是InnoDB实现一致性读的重要机制。数据库通过保存必要的历史版本信息，使某些普通查询不必为了读取数据而直接阻塞正在进行的写操作。不同隔离级别下，事务能够看到的数据版本并不完全相同，因此MVCC和事务隔离级别必须结合起来理解。

MySQL常见的事务隔离级别包括READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。READ UNCOMMITTED允许读取其他事务尚未提交的数据，因此可能产生脏读；READ COMMITTED要求读取已经提交的数据，但同一个事务前后两次查询可能得到不同结果；REPEATABLE READ提供更稳定的事务内一致性视图；SERIALIZABLE则进一步提高并发访问限制，以换取更强的隔离效果。

需要注意的是，隔离级别不是简单的“越高越好”。隔离程度提高通常意味着并发访问受到更多限制，锁竞争或者等待也可能增加。具体选择应该根据业务的一致性要求、SQL访问模式、索引设计和实际并发压力决定，而不是按照“金融系统一定使用某个级别、CMS一定使用另一个级别”的固定模板配置。

在电商系统中，库存扣减就是一个非常典型的并发事务问题。假设库存只剩1件，两个用户几乎同时提交订单，如果应用先读取库存，然后在应用层判断“库存大于0”，最后再执行普通UPDATE，就可能出现两个请求同时认为库存充足的情况。更可靠的方式通常是让条件判断和修改尽可能在数据库的一条原子UPDATE中完成，例如：

UPDATE inventory
SET stock = stock - 1
WHERE product_id = 1001
AND stock > 0;

然后检查受影响行数。如果结果为1，说明本次扣减成功；如果结果为0，则需要根据业务判断是库存不足还是其他条件没有满足。对于复杂库存模型，还需要结合锁、唯一约束、订单状态以及事务隔离策略进行整体设计。

事务边界也是生产系统性能的重要因素。事务并不是越大越安全。一个事务持续时间越长，持有锁或者占用相关资源的时间通常也越长，其他请求就可能产生锁等待。更危险的是，在数据库事务内部执行慢速HTTP请求、调用第三方支付接口或者等待人工处理，会把一个本来几毫秒就能完成的数据库事务拖成长期事务。

因此，通常应该尽量缩短事务持续时间，把数据库内部必须保持一致的操作放进事务，把不需要数据库原子性的工作放到事务之外。对于复杂流程，则通过消息队列、Outbox、幂等键、状态机等机制解决跨系统一致性问题。

死锁也属于事务系统中的正常并发问题，而不是简单的数据库故障。两个事务如果按照不同顺序锁定资源，就可能形成循环等待。例如事务A先锁定记录1再等待记录2，而事务B先锁定记录2再等待记录1。InnoDB能够检测部分死锁并主动回滚其中一个事务，应用程序则需要捕获相应错误，并根据业务安全地重试。

innodb_lock_wait_timeout主要控制锁等待超时，并不是“防止死锁”的开关。死锁和普通锁等待是两个相关但不同的问题。生产系统真正应该做的是统一访问顺序、优化事务范围和索引、降低锁竞争，同时对可重试的事务错误设计有限次数的重试机制。

排查事务问题时，可以使用SHOW ENGINE INNODB STATUS查看InnoDB当前状态以及最近的死锁信息。在较新的MySQL环境中，还可以结合Performance Schema、系统监控和数据库指标观察锁等待、活跃事务、长事务以及连接池压力。真正需要监控的不是某一个孤立的CPU百分比，而是事务持续时间、锁等待时间、死锁次数、回滚次数、连接池使用情况和慢SQL等指标。

还有一个经常被忽略的问题是存储引擎。事务能力并不是仅由START TRANSACTION这几个SQL关键字决定。实际使用中应确认相关表使用支持事务的存储引擎，并理解不同引擎的行为差异。现代MySQL应用通常以InnoDB作为主要事务存储引擎，因为它提供行级并发控制、MVCC、崩溃恢复以及外键等能力。

真正成熟的事务设计，最终并不是记住COMMIT和ROLLBACK两条命令，而是能够回答几个更实际的问题：这个业务的事务边界在哪里？哪些操作必须同时成功？出现异常时哪些变化必须撤销？多个请求同时执行时允许看到什么结果？外部系统参与后如何保证最终一致？发生死锁或者瞬时故障后能不能安全重试？

数据库事务解决的是数据状态的一致性问题，却不能替整个应用解决所有业务一致性问题。好的系统设计，会把事务控制、锁机制、MVCC、索引设计、异常处理、幂等机制和消息投递放在同一个整体中考虑。COMMIT和ROLLBACK只是入口，真正决定系统可靠性的，是开发者如何划定事务边界，以及如何处理并发、失败和重试。