只有InnoDB能真正保障ACID，因其通过redo log确保持久性、undo log支撑原子性和隔离性、行级锁与next-key lock实现可重复读；MyISAM不支持事务，DDL会隐式提交，ACID依赖引擎机制而非SQL本身。
MySQL 通过事务（
/
）配合存储引擎（主要是 InnoDB）的底层机制来保证 ACID，不是 SQL 本身具备该能力，也不是所有引擎都支持——MyISAM 就完全不支持事务。
为什么只有 InnoDB 能真正保障 ACID
InnoDB 是 MySQL 默认且唯一在生产中被广泛用于事务场景的引擎。它通过以下机制协同工作：
（重做日志）确保
Durability
：事务提交前，变更先写入磁盘上的
，崩溃后可重放恢复
（回滚日志）支撑
Atomicity
和
Isolation
：记录行修改前的镜像，用于回滚或 MVCC 快照读
行级锁 +
实现可重复读（
）隔离级别，避免幻读
所有 DML 操作（
/
/
）在事务内自动受锁和日志保护；DDL（如
）默认隐式提交，无法回滚
显式事务中哪些操作会意外中断 ACID 保证
即使写了
，以下行为会让事务提前结束或失效：
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
执行
、
、
等 DDL 语句 → 自动触发
，之前未提交的变更立即落库且不可回滚
执行
以外的非事务语句（如
）→ 切换会话模式，后续语句不再受当前事务控制
客户端连接异常断开（未发
或
）→ InnoDB 会检测并自动回滚该事务，但依赖
和连接池配置
在
隔离级别下执行多次
，结果可能不一致 → 这是隔离级别允许的行为，不违反 ACID，但容易误判为“不一致”
如何验证一条 UPDATE 是否真的在事务中生效
不能只看客户端返回“Query OK”，要确认是否处于有效事务上下文：
检查
：值为
才表示手动事务模式启用
执行
：能看到当前活跃事务 ID 和状态（
/
）
在另一会话中查同一行数据：若未
，应看到旧值（
下）或新值（
下），而非报错或阻塞 —— 阻塞说明锁已生效，是事务起作用的信号
故意让事务超时：
，然后用
锁住某行，再在另一会话尝试更新同一行 → 应收到错误
或超时提示
ACID 不是开关，而是 InnoDB 在日志、锁、内存结构之间精密协作的结果。最容易被忽略的是：事务边界由引擎控制，不是 SQL 语句决定；DDL 会偷偷提交；隔离级别差异直接影响“一致性”的表现形式——这些细节一旦出错，表面看 SQL 执行成功，实际已破坏业务语义。
START TRANSACTIONBEGINredo logib_logfile*undo lognext-key lockREPEATABLE READINSERTUPDATEDELETEALTER TABLEBEGINCREATEDROPALTERCOMMITSELECTSET autocommit = 1COMMITROLLBACKinnodb_lock_wait_timeoutREAD COMMITTEDSELECTSELECT @@autocommit0SELECT trx_id, trx_state, trx_started FROM information_schema.INNODB_TRXRUNNINGLOCK WAITCOMMITREPEATABLE READREAD COMMITTEDSET innodb_lock_wait_timeout = 1UPDATEERROR 1205 (40001): Deadlock found when trying to get lock