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。
