MyISAM 与 InnoDB 有什么区别？如何选择？

MyISAM 不支持事务和外键，适合读多写少的场景；InnoDB 支持事务、外键和行级锁定，适合高并发写操作。选择时根据应用需求决定：需要事务和高并发写入时选 InnoDB，读多写少时可选 MyISAM。

一、核心区别对比

特性	InnoDB	MyISAM
事务支持	✅ 完整 ACID 事务（原子性、一致性等）	❌ 不支持事务
锁机制	行级锁（高并发写入性能优）	表级锁（写操作阻塞全表）
外键约束	✅ 支持外键，保障数据完整性	❌ 不支持外键
崩溃恢复	✅ Redo/Undo 日志自动恢复	❌ 需手动修复（REPAIR TABLE）
索引结构	聚簇索引（数据与主键索引绑定）	非聚簇索引（数据与索引分离）
全文索引	✅ MySQL 5.6+ 支持	✅ 原生支持
COUNT(*) 性能	需全表扫描（慢）	直接读取缓存计数（极快）
存储文件	表空间（.ibd 或共享 ibdata）	三文件：.frm（结构）、.MYD（数据）、.MYI（索引）
适用场景	高并发读写、事务型业务（支付、电商）	读密集型、非事务场景（日志、报表）

二、性能与行为差异

1. 并发处理能力

   • InnoDB：行级锁 + MVCC（多版本并发控制），允许多个事务同时读写不同行，适合高并发写入场景。

   • MyISAM：表级锁导致写操作阻塞全表，高并发下性能急剧下降。

2. 数据安全与恢复

   • InnoDB：通过 Redo Log 和 Undo Log 保证崩溃后数据自动恢复，避免丢失。

   • MyISAM：崩溃后易损坏，需手动执行 REPAIR TABLE，且可能丢失部分数据。

3. 存储效率与查询速度

   • MyISAM：索引压缩率高，纯读场景（如SELECT COUNT(*)）速度更快，适合数据仓库。

   • InnoDB：聚簇索引减少磁盘 I/O，但需额外存储事务日志，空间占用更高。

4. 特殊场景行为

   • 模糊更新（如UPDATE ... WHERE name LIKE '%abc%'）：

     • InnoDB 可能退化为表级锁（因无法确定扫描范围）。

     • MyISAM 始终表级锁，无退化问题但并发性更差。

三、选型黄金法则

✅ 优先选择 InnoDB 的场景

1. 需要事务支持：如支付系统、订单处理（转账需原子性）。

2. 高并发写入：社交 feed 流、实时库存更新等。

3. 数据完整性要求高：需外键约束关联多表（如用户-订单关系）。

4. 系统稳定性优先：避免崩溃后手动修复，保障服务 SLA。

⚠️ 考虑 MyISAM 的场景

1. 读占比 >95%：如历史日志分析、BI 报表生成（COUNT(*)频繁且无写操作）。

2. 全文搜索需求：MySQL 5.6 前需依赖 MyISAM 的全文索引（现可用 InnoDB + Elasticsearch 替代）。

3. 内存受限环境：MyISAM 内存占用更低，但需权衡数据安全风险。

混合使用与迁移建议

• 分表策略：核心业务表用 InnoDB（如订单），日志表用 MyISAM（如访问记录）。

• 迁移步骤：

  ALTER TABLE logs ENGINE=MyISAM;  -- 转为 MyISAM
  ALTER TABLE orders ENGINE=InnoDB; -- 转为 InnoDB

  注意：大表迁移需停机维护，避免锁表超时。

四、总结：一句话决策

• 现代默认选择：MySQL 5.5+ 默认引擎为 InnoDB，无特殊需求直接选它。

• MyISAM 仅存场景：纯读 + 无事务 + 低内存 + 老旧系统兼容（新项目避免使用）。