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→MyISAMDDL 阻塞所有查询，换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），字段长度设计要重新评估。
