innodb 和 myisam 核心差异在于设计目标不同：innodb 面向事务安全、高并发与数据一致性，myisam 面向简单读取、低开销与静态数据；mysql 5.6+ 默认使用 innodb，新项目通常无需考虑 myisam。
InnoDB 和 MyISAM 是 MySQL 最经典的两种存储引擎，核心差异不在“快慢”，而在于设计目标完全不同：InnoDB 为事务安全、高并发、数据一致性而生；MyISAM 为简单读取、低开销、静态数据而设。如今 MySQL 5.6+ 默认使用 InnoDB，绝大多数新项目已无需考虑 MyISAM。
事务与数据安全
InnoDB 完全支持 ACID 事务，具备回滚（ROLLBACK）、崩溃恢复（通过 redo log + undo log）、MVCC 多版本并发控制等能力。数据库意外宕机后能自动恢复到一致状态。
MyISAM 不支持事务，任何写操作（INSERT/UPDATE/DELETE）都是立即生效的。一旦中断（如断电），数据文件（.MYD）极易损坏，且无法自动修复，只能依赖备份或 myisamchk 工具尝试抢救。
- InnoDB：适合订单、支付、用户账户等强一致性场景
- MyISAM：仅适用于日志归档表、报表快照等“写入一次、长期只读”的极少数情况
锁机制与并发能力
InnoDB 默认使用行级锁，锁定粒度小，多用户同时修改不同行时互不干扰，配合 MVCC 实现高并发读写。但要注意：行锁依赖索引——若 WHERE 条件未命中索引，会退化为表锁。
MyISAM 只支持表级锁：一个写操作（如 UPDATE）会锁住整张表，期间所有其他写请求和部分读请求都会被阻塞。虽然不会死锁，但并发吞吐量很低。
- InnoDB 的意向锁（IS/IX）是隐式加的，用于协调表锁与行锁共存
- MyISAM 的读锁允许并发读，但写锁会排斥一切读写，且写优先级高于读，容易造成读饥饿
索引与数据组织方式
InnoDB 使用聚簇索引：主键索引的叶子节点直接存放完整行数据，因此必须有主键（无显式主键时会自建隐藏主键）。辅助索引（二级索引）叶子节点存的是主键值，查数据需“回表”一次。
MyISAM 使用非聚簇索引：索引文件（.MYI）和数据文件（.MYD）完全分离，所有索引（包括主键）叶子节点都存数据行的物理地址指针。
- InnoDB 表空间默认为独立 ibd 文件（含数据+索引），也支持共享表空间
- MyISAM 每张表固定生成 .frm（结构）、.MYD（数据）、.MYI（索引）三个文件
- 主键选择对 InnoDB 很关键：短、稳定、单调递增（如 BIGINT AUTO_INCREMENT）更优
功能支持与典型场景
InnoDB 支持外键约束、全文索引（5.6+）、自增列（auto_increment）、在线 DDL（部分操作）、缓冲池（Buffer Pool）加速访问。
MyISAM 支持全文索引（早期优势，现已被 Elasticsearch/Solr 等替代）、表压缩（.MYD 可用 myisampack 压缩）、COUNT(*) 极快（因内存中缓存了行数）。
- 需要 COUNT(*) 且无 WHERE？MyISAM 确实更快，但实际业务中几乎总带条件，InnoDB 优化后差距已微乎其微
- 需要外键或事务？MyISAM 直接不满足，强行转换会失败或静默失效
- 纯历史数据归档表？MyISAM 压缩后体积小、查询快，可作为补充方案
现代应用中，InnoDB 几乎覆盖全部需求。MyISAM 更像一种兼容性存在，除非你明确知道为什么还要用它，否则就别用。
