InnoDB vs MyISAM 核心区别
| 特性 | InnoDB | MyISAM |
|---|---|---|
| 事务支持 | ✅ 完整支持 ACID 事务 | ❌ 不支持事务 |
| 锁粒度 | 🔒 行级锁（默认），支持高并发 | 🔒 表级锁，并发写性能差 |
| 外键约束 | ✅ 支持外键 | ❌ 不支持外键 |
| 崩溃恢复 | 🔧 支持崩溃后的安全恢复（redo log） | 🚫 崩溃后易数据损坏 |
| 索引结构 | 🌳 聚簇索引（数据文件本身是B+树索引的一部分） | 📚 非聚簇索引（数据与索引分离存储） |
| 全文索引 | ✅ MySQL 5.6+ 支持全文索引 | ✅ 支持全文索引（较早版本优势） |
| 存储文件 | 📂 .ibd（数据+索引） / .ibdata（系统表空间） | 📂 .MYD（数据） + .MYI（索引） + .frm（表结构） |
| COUNT(*) 性能 | ⏱️ 需全表扫描（除非用二级索引统计） | ⚡ 直接读取存储的计数（myisam引擎表单独记录） |
| 压缩能力 | ❌ 不支持压缩表 | ✅ 支持压缩表（只读场景优化存储） |
| 适用场景 | 🏦 高并发写/事务型应用（OLTP） | 📊 读密集型/分析型应用（OLAP） |
事务支持
InnoDB支持完整的ACID属性事务(原子性、一致性、隔离性、持久性)。这是InnoDB最核心的优势之一。它允许将一组SQL操作作为一个不可分割的工作单元来执行，如果其中任何一条语句失败，整个事务可以回滚(ROLLBACK)，保证数据处于一致状态。这对于需要高数据完整性的应用(银行系统)是必不可少的。
MyISAM不支持事务。每条SQL语句都是原子的，无法将多条语句组合成一个事务并保证其原子性。如果执行过程中发生故障(eg：断电)，可能只执行了部分语句，导致数据不一致。只支持表级锁定语句(eg：LOCK TABLES)，无法提供细粒度的事务控制。
锁机制
InnoDB 采用了行级锁和表级锁相结合的锁机制。在大多数情况下，它只对操作的数据行进行锁定，而不是整个表，这样可以大大提高并发性能。只有在一些特殊情况下，如全表扫描时，才会使用表级锁。
MyISAM 则只支持表级锁。当对一个 MyISAM 表进行写操作时，会锁定整个表，其他用户对该表的读操作和写操作都会被阻塞。这在并发访问较高的场景下，可能会导致性能问题。
外键支持
InnoDB 支持外键约束，这使得在数据库设计中可以更好地维护数据的完整性和一致性。通过外键，你可以定义表与表之间的关联关系，并且 InnoDB 会自动检查这些关系，确保数据的合法性。
而 MyISAM 不支持外键约束。如果你需要在数据库中使用外键，那么 InnoDB 将是更好的选择。
性能场景对比
| 操作类型 | InnoDB优势场景 | MyISAM优势场景 |
|---|---|---|
| 频繁写入 | ✅ 行锁+MVCC支持高并发写 | ❌ 表锁导致阻塞 |
| 复杂查询 | ⚠️ JOIN多时可能慢（需优化索引） | ⚡ 简单COUNT(*) / 全表扫描更快 |
| 全文搜索 | ✅ MySQL 5.6+性能持平 | ✅ 老版本唯一选择 |
| 数据压缩 | ❌ 不支持 | ✅ 只读数据可节省60%+空间 |
生产环境选择建议
✅ 优先用 InnoDB（默认引擎）
- 典型场景：订单系统、银行交易、用户账户等有事务需求的业务
- 关键原因：数据安全 > 极致读性能
⚠️ 谨慎选 MyISAM
- 可用场景：
- 只读的数据仓库报表（配合压缩表）
- 临时中间表（需频繁全表扫描）
- 全文索引需求且MySQL版本 < 5.6
- 致命缺陷：表锁+无崩溃恢复，不适用于核心业务表
现代MySQL趋势： MySQL 5.5+ 默认引擎改为InnoDB，MyISAM逐渐被淘汰（甚至官方文档标注”deprecated”）。 阿里云RDS等云数据库已禁止创建MyISAM表。
总结
InnoDB强在事务安全（ACID）和高并发（行锁+MVCC），适合OLTP系统；MyISAM优势是读性能和压缩，但缺乏事务和行锁，已逐渐被淘汰。现代数据库设计默认使用InnoDB，仅在极端读场景考虑MyISAM。
