MySQL事务ACID特性依赖InnoDB引擎、autocommit配置及显式控制：MyISAM不支持；autocommit=1时单语句自动提交；BEGIN后须COMMIT或ROLLBACK，否则事务挂起；原子性靠undo log但需主动回滚；隔离性受transaction_isolation影响；持久性由innodb_flush_log_at_trx_commit和sync_binlog共同保障。
MySQL 中事务的 ACID 特性不是靠“开启事务”这个动作自动生效的，而是依赖 InnoDB 存储引擎 + 正确配置 + 显式控制才能真正起作用。MyISAM 不支持事务，autocommit=1 时单条语句会自动提交，BEGIN 后没 COMMIT 或 ROLLBACK 会导致连接挂起或隐式提交——这些是绝大多数数据不一致问题的根源。
确认存储引擎和 autocommit 状态
事务只在 InnoDB 表上有效，且必须关闭自动提交或显式开启事务。MyISAM 表执行 BEGIN 无意义，也不会回滚。
- 检查表引擎：
SHOW CREATE TABLE table_name;，确认ENGINE=InnoDB - 查看当前 autocommit 值：
SELECT @@autocommit;，生产环境建议设为0 - 临时关闭：
SET autocommit = 0;；但更推荐每次用BEGIN/START TRANSACTION显式包裹 - 注意：某些 ORM（如 Django 默认）会自动管理事务边界，但裸 SQL 或 JDBC 需手动控制
原子性靠 undo log，但回滚只发生在显式 ROLLBACK 或异常中断时
UNDO LOG 是 InnoDB 实现原子性的底层机制，但它不会“自动感知业务失败”。哪怕你写了 5 条 UPDATE，只要没触发错误、也没执行 ROLLBACK，MySQL 就认为你要继续——哪怕应用层已经报错退出。
- 常见错误：PHP/Python 中 try-catch 捕获了 SQL 异常，但忘了调用
ROLLBACK，导致连接里事务仍处于打开状态 - 更隐蔽的问题：长事务未及时提交，占用锁和
undo log空间，拖慢其他查询 - 验证是否真回滚：在事务中执行
SELECT查看中间状态，再ROLLBACK后重查，确认数据还原 -
ROLLBACK只对当前事务有效，不能回滚已COMMIT的内容
隔离性由 transaction_isolation 决定，可重复读不是绝对安全
InnoDB 默认隔离级别是 REPEATABLE READ，它通过 MVCC + 间隙锁防止幻读，但仍有两类典型漏网场景：
- 写偏移（write skew）：两个并发事务各自读取不同行、各自修改、各自提交，结果违反业务约束（如总库存超限）。MySQL 原生不解决，需应用层加
SELECT ... FOR UPDATE或唯一约束兜底 - 大范围更新缺失 WHERE 条件：
UPDATE users SET status=1;在 RR 下仍可能被其他事务的 INSERT 干扰，尤其涉及索引扫描时 - 检查当前级别：
SELECT @@transaction_isolation;；调整：SET SESSION transaction_isolation='READ COMMITTED'; - 高并发读写场景下，
READ COMMITTED能减少锁等待，但要接受“不可重复读”
持久性依赖 redo log 刷盘策略，但 sync_binlog 和 innodb_flush_log_at_trx_commit 才是关键
REDO LOG 保证崩溃恢复，但它的落盘时机由两个参数控制，直接影响“已提交是否真不丢”：
-
innodb_flush_log_at_trx_commit = 1（默认）：每次COMMIT都刷盘，最安全，性能略低 -
= 0：每秒刷一次，崩溃可能丢失一秒事务；= 2：写入 OS 缓存即返回，崩溃时若 OS 也宕了可能丢数据 -
sync_binlog = 1：确保 binlog 与 redo log 一致，主从复制或恢复时才不会出现“主库有、从库无”的数据裂口 - 线上 OLTP 系统不要调低这两个值；压测或日志类场景可酌情放宽
ACID 不是开关，是多个组件协同的结果：引擎类型决定能否用事务，autocommit 和 BEGIN/COMMIT 控制边界，undo log 和锁机制保障原子与隔离，redo log 刷盘策略决定持久底线。最容易被忽略的是——事务生命周期必须由应用代码完整闭环，数据库不会替你判断“这里该回滚”。
