事务的ACID特性是什么？
在开发电商系统时，经常会遇到这样的场景：用户下单并扣款，必须保证两个操作同时成功或同时失败。如果只扣了钱但订单没生成，用户肯定不干；反过来，生成了订单却没扣钱，商家就要亏本。这时候，数据库的事务机制就派上用场了，而它的核心就是ACID特性。
ACID是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）的缩写，这四个特性共同确保了数据库操作的可靠性。
原子性：要么全做，要么全不做
原子性就像一个不可分割的动作。比如银行转账，从A账户转500元到B账户，包含两个步骤：A减500，B加500。如果中间断电导致只完成了第一步，那显然不行。事务的原子性保证这两个操作要么全部完成，要么一个也不执行，不会出现中间状态。
在代码层面，可以用BEGIN、COMMIT和ROLLBACK来控制：
BEGIN;<br>UPDATE accounts SET balance = balance - 500 WHERE user = 'A';<br>UPDATE accounts SET balance = balance + 500 WHERE user = 'B';<br>-- 如果上面任意一条失败<br>-- 则执行<br>ROLLBACK;<br>-- 如果都成功<br>COMMIT;一旦出错回滚，所有更改就像没发生过。
一致性：数据始终符合规则
一致性指的是事务执行前后，数据库都处于合法状态。比如账户余额不能为负数，外键必须指向存在的记录。即使并发执行多个事务，最终结果也必须满足这些约束。
注意，一致性不是由事务单独保证的，而是靠原子性、隔离性和持久性共同作用的结果。它更像是一个目标，而ACID中的其他三项是实现这个目标的手段。
隔离性：并发操作互不干扰
现实系统中，不可能等一个人操作完才让下一个人开始。比如双11抢购，成千上万人同时下单，数据库必须支持并发处理。
隔离性就是为了解决并发带来的问题。常见的并发问题有：
- 脏读：读到了别人还没提交的数据
- 不可重复读：同一事务中两次读取同一数据，结果不一样
- 幻读：第一次查询有5条记录，第二次却变成6条
数据库通过不同的隔离级别来控制这些问题的程度，比如读未提交、读已提交、可重复读、串行化。MySQL默认使用可重复读，能有效避免大部分异常。
持久性：一旦提交，永久生效
当你收到“支付成功”的提示，哪怕下一秒数据库崩溃重启，这笔交易记录也不能消失。这就是持久性的意义。
数据库通常通过写日志（如redo log）来实现。事务提交时，先确保日志落盘，即使数据还没完全写入主文件，恢复时也能根据日志重新应用操作，保证数据不丢。
就像你编辑文档时开启自动保存，就算电脑突然蓝屏，重启后还能找回大部分内容。
实际应用中的取舍
理论上ACID都很重要，但现实中往往需要权衡。比如为了提高性能，可能会降低隔离级别，允许一定程度的不可重复读。或者在高可用架构中，主从同步延迟可能导致短暂的不一致。
关键是在具体业务场景下做出合理选择。金融系统对一致性要求极高，宁可牺牲速度；而社交平台可能更看重响应速度，可以容忍短暂的数据延迟。
理解ACID，不只是背概念，而是学会在复杂环境中判断：什么时候该强一致性，什么时候可以适当放松，这才是进阶的关键。