在MySQL中，事务是一组要么全部成功要么全部失败的操作单元，其核心由ACID四个特性来约束。原子性保证操作不可拆分，一致性确保数据始终满足业务规则，隔离性使并发事务互不干扰，持久性让提交结果永久生效。下面我们逐一拆解每个特性的实现原理与工程意义。
原子性（Atomicity）
原子性要求事务内的所有操作作为一个整体执行，只要其中一步出错，已经执行的改动也必须被撤销。MySQL通过回滚日志（undo log）来实现这一点。事务开始前，引擎会记录修改前的数据镜像，当执行rollback或发生错误时，就利用这些镜像把数据还原。
例如一个转账事务，从A扣钱、给B加钱，若第二步失败，系统必须撤销第一步。下面是一段示意性的SQL，展示显式事务如何通过回滚保证原子性：
START TRANSACTION; UPDATE account SET balance = balance - 100 WHERE name = 'A'; UPDATE account SET balance = balance + 100 WHERE name = 'B'; -- 如果第二步出错，执行以下语句 ROLLBACK; -- 否则提交 COMMIT;
原子性避免了“钱扣了但没到账”的中间状态。需要注意，原子性只关心事务范围内的改动，不处理应用层逻辑错误，比如你更新了错误的行，数据库仍认为事务成功。
一致性（Consistency）
一致性指事务必须将数据库从一种合法状态转换到另一种合法状态，包括主键唯一、外键约束、字段类型以及业务规则。它并不是由某一种独立机制单独实现，而是原子性、隔离性、持久性加上数据库约束共同作用的结果。
举例来说，账户余额不能为负，这可以在表中设置检查约束，或者在应用层结合事务控制。若只靠事务而不设约束，依然可能写入非法值。下列代码展示在建表时通过约束辅助一致性：
CREATE TABLE account ( id INT PRIMARY KEY, name VARCHAR(20), balance INT CHECK (balance >= 0) );
当并发事务试图把同一账户扣成负数时，约束会拒绝提交，从而维护一致。一致性更偏向业务正确性的总目标，开发时要同步考虑数据库层与应用层规则。
隔离性（Isolation）
隔离性解决多个事务同时执行时的互相影响。MySQL提供读未提交、读已提交、可重复读、串行化四种级别。默认的可重复读依靠多版本并发控制（MVCC）与间隙锁来防止脏读和幻读。
MVCC通过给每行数据维护版本链，让读操作访问快照而不阻塞写。下面的例子演示了隔离级别设置以及可能观察到的现象差异：
-- 设置会话隔离级别 SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; START TRANSACTION; SELECT balance FROM account WHERE name = 'A'; -- 此时另一事务修改并提交了A的余额 SELECT balance FROM account WHERE name = 'A'; -- 两次查询结果一致，体现可重复读 COMMIT;
隔离性越强，并发性能往往越低。串行化虽最安全但基本退化为单线程执行。实际系统多在可重复读基础上，用合理的索引减少锁冲突，平衡正确与效率。
持久性（Durability）
持久性意味着一旦事务提交，其结果就不会因系统崩溃而丢失。MySQL使用重做日志（redo log）达成该目标。提交时，改动先写入redo log并落盘，再异步刷新到数据文件。
即使刚提交就断电，重启后InnoDB也会依据redo log重放操作。以下伪代码说明写入流程：
事务提交: 1. 写redo log到内存缓冲 2. 刷redo log到磁盘(根据innodb_flush_log_at_trx_commit) 3. 返回客户端成功 4. 后台线程将脏页刷入表空间
参数innodb_flush_log_at_trx_commit为1时最安全，每次提交都落盘；为0或2则有丢失窗口。持久性保障了核心业务数据可靠，但也会带来一定写放大，需结合硬件缓存策略调优。
总结与实践建议
ACID四特性彼此支撑：原子性借助undo log回滚，持久性依靠redo log重放，隔离性通过锁与MVCC实现，一致性是前三者和约束的总成效。设计高并发系统时，应明确事务边界，避免长事务占用连接与锁。
建议在订单、扣库存等场景使用单一事务并配合合理索引；对一致性要求极高的金额计算，可叠加检查约束。理解底层日志与版本控制，比单纯记忆概念更能帮你排查线上数据异常。