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，根据可见性规则判断该读哪个版本。
典型陷阱：
- 在
REPEATABLE READ下，事务内多次SELECT看到相同结果，但若中间有其他事务插入新行且满足 WHERE 条件，可能产生幻读 —— 这时仅靠 MVCC 不够，InnoDB 会自动加Gap Lock拦住插入，但前提是 WHERE 条件命中了索引 - 用
SELECT ... LOCK IN SHARE MODE会阻塞其他 X 锁，但不阻塞 S 锁；而SELECT ... FOR UPDATE会升级为 X 锁，连 S 锁也阻塞 —— 很多死锁源于此处误判 - 无索引的
WHERE条件（如name = '张三'且name无索引），InnoDB 无法精准加行锁，会退化为全表扫描+表级意向锁，高并发下直接卡死
事务里能混用不同存储引擎吗？
能语法上执行，但不能真正事务保护。例如一个事务里对 InnoDB 表 UPDATE，又对 MyISAM 表 INSERT，当执行 ROLLBACK 时：
- InnoDB 表操作会被撤销（因它自己管理 undo log）
- MyISAM 表操作**不会回滚**（它根本不支持事务，也没有 undo log）
- 最终结果是数据不一致 —— 这就是典型的“伪事务”
更隐蔽的问题是：有些 ORM（如早期 Django）默认把 CREATE TABLE 的引擎设为 MyISAM，或某些迁移脚本手动指定 ENGINE=MyISAM，上线后才发现事务失效。查表引擎用 SHOW CREATE TABLE tbl_name，别只看 SELECT ENGINE FROM information_schema.TABLES。
