InnoDB是MySQL默认且最常用事务引擎，因其唯一完整支持ACID、行锁、MVCC、外键和崩溃安全五项OLTP硬需求；MyISAM等引擎在事务回滚、并发控制等方面存在根本缺陷。
为什么 InnoDB 是 MySQL 默认且最常用的事务引擎
InnoDB 自 MySQL 5.5.8 起成为默认存储引擎，根本原因不是“历史选择”，而是它唯一完整实现了 ACID、行锁、MVCC、外键和崩溃安全（crash-safe）这五项 OLTP 场景的硬性需求。MyISAM 等引擎在事务提交、并发更新、主从一致性等环节会直接失效——比如一个转账操作中只执行了扣款没完成入账，MyISAM 就无法回滚，而 InnoDB 通过 redo log 和 undo log 两层日志保障原子性和持久性。
行锁 + MVCC 怎么协同解决高并发读写冲突
InnoDB 的行级锁（SELECT ... FOR UPDATE 或 UPDATE 触发行锁）只锁定实际访问的记录，而非整张表；同时默认开启可重复读（REPEATABLE READ）隔离级别，靠 MVCC 维护多个版本快照，让普通 SELECT 不加锁也能读到事务开始时的一致视图。这意味着：同一张订单表，用户 A 修改第 100 行，用户 B 可以同时安全地查询第 200 行或插入新行，互不阻塞。
- 注意间隙锁（Gap Lock）：在范围查询（如
WHERE id BETWEEN 10 AND 20）时，InnoDB 会锁住区间空隙，防止幻读；但这也可能引发意外死锁，尤其在非唯一索引上 - 避免全表扫描：若查询没走索引，InnoDB 会退化为锁全表（实际是锁所有索引记录+间隙），性能雪崩
-
autocommit=1下每个语句自动成事务，看似简单，但UPDATE执行慢时会长时间持锁，务必确认 WHERE 条件能命中索引
表空间与文件管理：.ibd 文件到底存什么
从 MySQL 5.6.6 开始，默认启用独立表空间（innodb_file_per_table=ON），每张 InnoDB 表对应一个 .ibd 文件，里面包含该表的数据页、索引页、插入缓冲（Insert Buffer）、事务系统页等全部结构。系统表空间（ibdata1）则只保留元数据、undo log 段、doublewrite buffer 等全局资源。
- 好处：单表
DROP后磁盘空间立即释放；可使用ALTER TABLE ... ENGINE=InnoDB在线重建表并回收碎片 - 风险：
ibdata1一旦膨胀就无法收缩，若误关innodb_file_per_table，后续建表会持续往ibdata1写，最终撑爆磁盘 - 迁移注意：
.ibd文件不能直接拷贝到另一实例使用，需配合FLUSH TABLES ... FOR EXPORT+DISCARD TABLESPACE/IMPORT TABLESPACE
崩溃恢复靠什么？redo log 和 binlog 如何配合
InnoDB 的 crash-safe 能力依赖 redo log（物理日志，循环写，记录“某页某偏移改成了什么值”）和 server 层的 binlog（逻辑日志，追加写，记录“执行了哪条 SQL”）共同完成两阶段提交（2PC）。MySQL 崩溃重启后，先重放 redo log 中 prepare 状态的事务，再根据 binlog 是否完整决定是提交还是回滚。
- 关键配置：
innodb_flush_log_at_trx_commit=1（每次事务刷盘，强持久） vs=2（刷 OS 缓存，速度略快但掉电可能丢 1s 数据） - 主从复制依赖
binlog，所以即使只用 InnoDB，也必须开启log_bin；否则搭建不了复制，备份工具（如 mysqldump --master-data）也会失败 -
innodb_log_file_size太小会导致频繁 checkpoint，增大 IO 压力；太大则崩溃恢复时间变长，建议设为总缓冲池的 25% 左右（如innodb_buffer_pool_size=8G，则 log file 总大小设为 2G）
真正容易被忽略的是：InnoDB 的“事务安全”不等于“应用安全”。比如未加事务包裹的多条 SQL、应用层超时后连接中断但事务未 rollback、或长事务阻塞 purge 线程导致 undo log 膨胀——这些都不会报错，但会在某个深夜突然拖垮整个库。别只盯着引擎特性，得盯住自己写的每一行 SQL 是否落在事务边界内。
