MySQL事务的ACID特性指原子性、一致性、隔离性、持久性四项硬性保障。原子性靠undo log实现全做或全不做；一致性确保约束不被破坏；隔离性通过MVCC和行级锁防止并发异常；持久性依赖redo log保证提交即落地。
MySQL事务的特性就是ACID，它不是抽象概念，而是数据库在执行写操作时必须满足的四项硬性保障。这四个字母分别代表原子性、一致性、隔离性、持久性，缺一不可。
原子性（Atomicity）：要么全做，要么全不做
事务是一个不可分割的最小执行单元。其中所有SQL语句必须作为一个整体成功或失败——中间不能“卡一半”。比如转账操作包含“扣A账户”和“加B账户”两步，只要其中一步出错（如余额不足、网络中断、磁盘写满），整个事务就会回滚，A账户也不会被扣款。
实现靠的是red">undo log（回滚日志）：事务执行过程中，每条修改操作都会先记下旧值；一旦需要回滚，就用这些旧值把数据恢复到事务开始前的状态。
- 开启事务用 BEGIN 或 START TRANSACTION
- 成功提交用 COMMIT，失败回滚用 ROLLBACK
- 可设保存点：SAVEPOINT sp1；回滚到该点：ROLLBACK TO sp1
一致性（Consistency）：状态始终合法，规则永不破坏
一致性不是数据库自动“算对账”，而是指事务执行前后，数据库必须满足所有预定义的约束条件——比如主键唯一、外键关联有效、CHECK检查通过、触发器逻辑成立等。它不保证业务逻辑正确（那是程序员的责任），但保证数据库层面的数据完整性不被破坏。
例如转账后，A减100、B加100，总金额不变；如果因约束冲突（如插入重复主键）导致事务失败，数据库就不会让非法状态落地。
注意：一致性是ACID其他三项共同作用的结果——原子性防部分更新，隔离性防并发干扰，持久性防崩溃丢失，三者合力才守住一致。
隔离性（Isolation）：并发事务互不看见彼此中间态
多个事务同时运行时，每个事务都应像在独占数据库一样执行。一个事务未提交的修改，对其他事务不可见；否则会出现脏读、不可重复读、幻读等问题。
MySQL InnoDB通过MVCC（多版本并发控制）+ 行级锁实现，默认隔离级别是可重复读（REPEATABLE READ）：
- 读已提交（READ COMMITTED）：每次SELECT都看到最新已提交数据
- 可重复读（REPEATABLE READ）：事务内多次SELECT结果一致，避免不可重复读
- 串行化（SERIALIZABLE）：最高隔离，强制顺序执行，开销最大
可通过 SELECT @@transaction_isolation; 查看当前级别，用 SET SESSION TRANSACTION ISOLATION LEVEL ... 修改。
持久性（Durability）：提交即落地，断电也不丢
一旦事务执行 COMMIT 成功，它的所有修改就必须永久保存到磁盘，即使随后发生服务器宕机、断电或系统崩溃，重启后数据依然存在且完整。
InnoDB靠redo log（重做日志）实现：事务提交前，先把修改操作记录追加写入redo log文件（顺序I/O，快）；再异步刷盘到真正的数据页。崩溃恢复时，数据库会重放redo log中已提交但未落盘的变更。
注意：持久性依赖配置——若 innodb_flush_log_at_trx_commit = 1（默认），每次commit都同步刷redo log到磁盘，最安全；设为2则只写OS缓存，性能高但有秒级风险。
