InnoDB支持事务因其内核级实现ACID：redo log保持久性、undo log保原子性、MVCC+行锁+间隙锁保隔离性、约束与事务协同保一致性；非配置开关，而是引擎本质特性。
InnoDB 为什么能支持事务？关键不在“它声明支持”，而在底层日志和锁
因为 InnoDB 实现了 ACID 所需的四大机制：redo log 保持久性、undo log 保原子性、MVCC + 行锁 + 间隙锁 保隔离性、约束与事务协同保一致性。这不是靠配置开关，而是引擎内核级设计。
常见误解是“只要用 InnoDB 就自动有事务”——其实 MyISAM 表哪怕改名成 .ibd 文件也不会获得事务能力；反过来，InnoDB 表如果被误设为 autocommit = 1，每条语句仍是独立事务，看似“没出错”，实则丧失业务逻辑封装能力。
-
START TRANSACTION后必须显式COMMIT或ROLLBACK，否则连接断开时会自动回滚（注意：不是提交） - 外键检查、唯一索引冲突等失败会触发隐式回滚，但不会抛出 SQLSTATE ‘45000’ 这类自定义错误，容易漏捕获
- 没有主键的 InnoDB 表仍能事务，但会自建 6 字节
ROWID当聚簇索引，导致二级索引变大、范围查询效率下降
事务已 COMMIT，数据就真的不会丢了吗？
不一定。真正决定“是否丢”的是 innodb_flush_log_at_trx_commit 参数值，它控制 redo log 刷盘时机：
-
innodb_flush_log_at_trx_commit = 1（默认）：每次COMMIT都强制fsync到磁盘 → 最安全，性能最低 -
= 0：log buffer 每秒刷一次，崩溃可能丢失 1 秒内事务 → 常见于日志类表 -
= 2：每次COMMIT写入 OS cache，由 OS 异步刷盘 → 折中方案，但断电仍可能丢数据
很多线上事故不是代码写错，而是 DBA 把这个参数调成 0 却没同步告知应用层——你以为提交成功了，其实只在内存里。
为什么 SELECT 不加 FOR UPDATE 也能读到“一致的数据”？
这是 MVCC 在起作用，不是锁，也不是快照备份。InnoDB 每行自带两个隐藏字段：DB_TRX_ID（最后修改该行的事务 ID）、DB_ROLL_PTR（指向 undo log 中旧版本链）。事务启动时生成 ReadView，根据可见性规则判断该读哪个版本。
