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），字段长度设计要重新评估。
