17370845950

MySQL 5.5起默认存储引擎为InnoDB，因其支持事务、行级锁、外键和崩溃恢复，适合写多、高并发、强一致场景；MyISAM仅适合只读归档，而ENGINE选择应基于实际错误与行为判断。

MySQL 默认用的是 InnoDB，不是 MyISAM

MySQL 5.5 以后，InnoDB 就是默认存储引擎。如果你没显式指定 ENGINE=xxx，建表时自动用 InnoDB。很多老教程还说“MyISAM 更快”，那是基于十年前单核、无事务、纯读场景的结论——现在几乎不成立。

常见误操作：

CREATE TABLE logs (id INT) ENGINE=MyISAM;

结果导致后续加外键失败、崩溃后数据不一致、无法做行级锁，问题暴露时往往已上线多日。

InnoDB 和 MyISAM 的关键差异在哪

不是“谁快”，而是“解决什么问题”：

• 

  InnoDB 支持事务、行级锁、外键、崩溃恢复；写多、并发高、需数据强一致的场景必须选它
• MyISAM 表级锁、无事务、不支持外键，但 COUNT(*) 全表统计极快（因自带行数缓存），适合只读归档表或日志快照
• MEMORY 引擎只存内存，重启即丢，别用来存用户数据；ARCHIVE 压缩率高但只支持 INSERT + SELECT，适合冷备日志

性能陷阱：在 InnoDB 上执行 SELECT COUNT(*) FROM huge_table 会扫聚簇索引，比 MyISAM 慢几十倍——这不是引擎选错了，而是不该这么查。

什么时候真该换引擎？看错误和行为，不是看文档

以下信号说明当前引擎不合适：

• 频繁出现 Lock wait timeout exceeded 错误 → MyISAM 表级锁扛不住并发更新，换 InnoDB
• 主从延迟飙升，且 SHOW PROCESSLIST 里大量 Waiting for table metadata lock → MyISAM DDL 阻塞所有查询，换 InnoDB
• 应用层手动实现“转账逻辑”，靠代码控制先后顺序 → 本质是在补事务缺失，直接切 InnoDB 更可靠
• 表里有 FOREIGN KEY 定义却报错 Cannot add or update a child row → 引擎不是 InnoDB，MyISAM 完全忽略外键语法

ALTER TABLE ... ENGINE=InnoDB 不是万能解药

在线转换大表可能锁表数小时，尤其 MySQL 5.6 以前版本。生产环境务必先在从库验证：

• 确认磁盘空间够用（InnoDB 行格式、索引结构更占空间）
• 检查 innodb_file_per_table 是否开启，否则所有表数据混在 ibdata1 里，删表不释放空间
• 如果原表用 MyISAM 的全文索引，InnoDB 的 FULLTEXT 行为不同（比如停用词、分词粒度），要重测搜索结果

最常被忽略的一点：CHAR 类型在 MyISAM 中固定长度，在 InnoDB 中按实际内容存（尤其配合 utf8mb4），字段长度设计要重新评估。