MySQL默认使用InnoDB是因其满足现代业务对可靠性、并发与一致性的硬性需求：支持ACID事务、行级锁、外键约束、聚簇索引及自动崩溃恢复。
MySQL 默认使用 InnoDB，不是偶然选择，而是围绕现代业务对数据可靠性、并发能力和一致性提出的硬性需求做出的工程决策。
事务支持是核心门槛
InnoDB 是 MySQL 唯一完整实现 ACID 的内置引擎。这意味着：
- 原子性：通过 undo log 实现回滚，单个事务失败不影响其他操作
- 一致性：崩溃后能自动恢复到事务提交前或提交后的确定状态
- 隔离性：支持 READ UNCOMMITTED 到 SERIALIZABLE 四种级别，可按需控制并发读写行为
- 持久性：redo log + doublewrite buffer 确保已提交事务不因断电丢失
MyISAM 不支持事务，一次写入中断就可能留下半截脏数据——这对订单、支付、账户类系统是不可接受的。
高并发场景下必须用行级锁
当多个用户同时修改同一张表时：
- MyISAM 只能锁整张表，一个 UPDATE 正在执行，其他所有 SELECT/INSERT 都得排队
- InnoDB 锁的是具体行（甚至可以精确到索引记录），不同用户改不同订单，互不阻塞
尤其在电商、社交、金融类应用中，行级锁直接决定了系统能否扛住秒杀或突发流量。
数据完整性靠外键和聚簇索引兜底
InnoDB 是 MySQL 中唯一原生支持 FOREIGN KEY 的引擎，能强制约束父子表关系，比如删除用户前自动拦截仍有订单关联的操作。
它采用聚簇索引组织数据：
- 主键索引的叶子节点直接存整行数据，范围查询（如 WHERE id BETWEEN 100 AND 200）天然高效
- 二级索引叶子只存主键值，节省空间，也使主键设计变得关键（推荐用自增 INT 或 BIGINT）
崩溃恢复能力决定服务可用性
数据库宕机很常见，但业务不能停。InnoDB 的 WAL（Write-Ahead Logging）机制让恢复变成自动化流程：
- 启动时自动比对 redo log 和磁盘数据，补全未刷盘的已提交事务
- 利用 undo log 回滚未完成事务，保证重启后数据始终处于一致状态
这种能力让 InnoDB 成为生产环境默认选项——不用人工介入就能从故障中“自我修复”。
