播面 为什么MySQL 5.5之后将 InnoDB 作为默认的存储引擎？
MySQL 5.5（发布于2010年底）将默认存储引擎从 MyISAM 切换为 InnoDB，这是 MySQL 发展史上的一个重要里程碑。这一改变主要是为了适应现代互联网应用对高并发、数据完整性和高可用性的强烈需求。
以下是促使 MySQL 做出这一改变的核心原因：
1. 事务支持（ACID属性）与数据安全
- InnoDB： 提供了完整的事务（Transaction）支持，满足 ACID（原子性、一致性、隔离性、持久性）特性。它支持
COMMIT（提交）和ROLLBACK（回滚）。在电商、金融等业务中，如果一个多步操作（如扣款、发货）中途失败，InnoDB 可以回滚，保证数据不会错乱。 - MyISAM： 不支持事务。如果更新操作在中途崩溃，数据会处于半更新的不一致状态。
- 结论： 随着 Web 2.0 和电子商务的崛起，数据一致性变得至关重要，InnoDB 成为刚需。
2. 并发性能：行级锁 vs 表级锁
- InnoDB： 采用行级锁（Row-level Locking），并且支持 MVCC（多版本并发控制）。这意味着即使在同一个表中，多个用户也可以同时修改不同的行，读写操作互不阻塞，极大地提高了高并发环境下的吞吐量。
- MyISAM： 采用表级锁（Table-level Locking）。只要有一个用户在向表中写入数据，整个表就会被锁定，其他所有的读写请求都必须排队等待。
- 结论： 现代 Web 应用是典型的“高并发、多读写”场景，MyISAM 的表锁极易成为性能瓶颈。
3. 崩溃恢复能力（Crash Recovery）
- InnoDB： 拥有极强的崩溃恢复机制。它通过 Redo Log（重做日志） 记录了数据的修改。如果数据库突然断电或宕机，重启后 InnoDB 能够自动通过日志将未完成的事务回滚，并将已提交但未写入磁盘的数据恢复，做到“崩溃安全（Crash-safe）”。
- MyISAM： 崩溃后极易发生索引或数据损坏，重启后需要运行耗时极长的
REPAIR TABLE进行修复，甚至可能永久丢失数据。 - 结论： 企业级应用不能容忍长时间的宕机修复和数据丢失，InnoDB 的高可靠性胜出。
4. 外键支持（Foreign Keys）
- InnoDB： 原生支持外键关联，可以在数据库底层强制保证数据的引用完整性（Referential Integrity）。
- MyISAM： 不支持外键。如果在 MyISAM 中创建外键，MySQL 不会报错，但实际上没有任何约束效果。
5. 缓存机制的差异
- InnoDB： 拥有 Buffer Pool（缓冲池），会将数据和索引都缓存在内存中。对于热点数据，InnoDB 的读写基本在内存中完成，性能极高。
- MyISAM： 只有一个 Key Cache，只缓存索引，数据块的缓存完全依赖操作系统的文件系统缓存。
6. 商业与历史背景（幕后推手）
除了技术原因，商业环境的整合也是关键因素：
- 2005年，Oracle 收购了开发 InnoDB 引擎的 Innobase 公司。
- 2010年，Oracle 完成了对 Sun Microsystems（当时 MySQL 的母公司）的收购。
- 结果： 在这之前，MySQL 官方因为版权和商业竞争原因，一直把亲儿子 MyISAM 作为默认引擎。但当 Oracle 将 MySQL 和 InnoDB 统归于自己门下后，就不存在利益冲突了。Oracle 开始大力投资并优化 InnoDB，顺理成章地将其转为默认引擎。
总结对比
| 特性 | MyISAM (5.5之前的默认) | InnoDB (5.5之后的默认) |
|---|---|---|
| 事务支持 | ❌ 不支持 | ✅ 支持 (ACID) |
| 锁粒度 | 表级锁 (并发低) | 行级锁 + MVCC (并发高) |
| 崩溃恢复 | ❌ 差 (容易损坏，修复慢) | ✅ 极好 (Redo Log 自动恢复) |
| 外键支持 | ❌ 不支持 | ✅ 支持 |
| 缓存机制 | 只缓存索引 | 缓存数据 + 索引 (Buffer Pool) |
| 适用场景 | 读多写少、纯查询、历史归档 | 高并发、复杂业务、核心数据 |
补充说明：
过去 MyISAM 有两个优势——“全文索引（Full-Text Search）”和“空间函数（Spatial Indexes）”。但 MySQL 官方在随后的 5.6 和 5.7 版本中，也为 InnoDB 增加了对这两项特性的支持。至此，MyISAM 的最后一点优势也被抹平，InnoDB 成为了 MySQL 当之无愧的全能王者。