InnoDB崩溃后能自动恢复，MyISAM必须人工REPAIR TABLE；因InnoDB依赖redo log和undo log实现前滚与回滚，而MyISAM无事务日志，断电易致.MYD损坏、数据静默丢失且修复不保证完整性。
因为 MyISAM 在崩溃后无法自动恢复，而现代业务根本不敢用一个写坏就可能丢数据、还要手动 REPAIR TABLE 的引擎。
MyISAM 崩溃后必须人工干预，InnoDB 能自己“爬起来”
MyISAM 没有 redo log 和 undo log，断电或 kill -9 后，.MYD 文件极大概率损坏。修复只能靠 REPAIR TABLE，但这个命令不保证数据完整——它可能跳过损坏块、填充默认值、甚至静默丢弃整行。
InnoDB 则在崩溃重启时自动执行 crash recovery：重做已提交事务（靠 redo log），回滚未提交事务（靠 undo log），几分钟内回到一致状态。这对订单、支付、库存类业务是底线要求。
- MySQL 5.5 开始将
innodb设为默认，不是为了“先进”，而是因为myisam已经没法在线上活了 - 你查
SHOW VARIABLES LIKE 'default_storage_engine';，输出InnoDB才算确认
MyISAM 是表级锁，InnoDB 默认行级锁 + MVCC
一条 UPDATE users SET status=1 WHERE id=1005，MyISAM 会锁整张 users 表；InnoDB 只锁 id=1005 这一行——前提是 id 是主键或有索引。
这意味着：MyISAM 写操作期间，所有其他写请求排队，读请求也被阻塞（除非加 LOW_PRIORITY）；而 InnoDB 的行锁 + MVCC 让“1000 人抢同一商品”只争抢那一行库存，查订单、改地址、浏览列表全都不受影响。
- 注意：
WHERE条件没走索引（比如WHERE name LIKE '%abc'），InnoDB 也会退化为锁表 - 所以索引设计不能偷懒，否则行锁优势直接归零
InnoDB 的聚簇索引让主键查询更省 I/O
InnoDB 表里，主键就是数据本身的位置。执行 SELECT * FROM users WHERE id=123，通常一次磁盘 I/O 就拿到全部字段；而 MyISAM 需要先查 .MYI 得到物理偏移量，再按偏移量去读 .MYD，至少两次 I/O。
但这也带来一个容易被忽略的坑：没有显式定义主键的 InnoDB 表，MySQL 会悄悄生成一个隐藏的 row_id 当聚簇键。这会让二级索引变大、写入变慢，且 row_id 是全局递增的，高并发下可能成为热点。
- 建议始终用
BIGINT UNSIGNED AUTO_INCREMENT或带时间前缀的UUID作主键 - 避免用长字符串或复合主键，尤其是作为聚簇索引时
真正决定引擎选型的，从来不是“哪个更快”，而是“你敢不敢把核心业务数据交给它”。MyISAM 简单、快、文件清爽，但它假设系统永不崩溃、应用层永远能兜底——这种假设，在今天已经不成立。
