InnoDB是唯一支持事务、行级锁、外键和崩溃恢复的引擎，适用于订单、转账等需数据一致性的场景；MyISAM无事务、表级锁、不支持外键，仅适合纯读、全文检索等有限场景。
选错存储引擎不是性能问题，是数据一致性或并发能力直接崩掉的问题。InnoDB 和 MyISAM 不是“快慢之分”，而是“能不能做”和“敢不敢做”的区别。
事务和崩溃恢复必须用 InnoDB
只要业务里有转账、订单创建、库存扣减这类“多个操作必须全成功或全失败”的逻辑，InnoDB 是唯一选择。MyISAM 不支持 COMMIT 或 ROLLBACK，出错就只能靠应用层兜底，而多数兜底方案实际不可靠。
崩溃恢复也一样：MyISAM 崩溃后表可能损坏，需要手动运行 REPAIR TABLE，期间表不可读写；InnoDB 依赖重做日志（ib_logfile0）自动前滚+回滚，重启后基本秒级恢复。
- 金融、电商、支付类系统，
MyISAM直接排除 -
INSERT ... SELECT或批量导入中出错？MyISAM会留下脏数据，InnoDB可回滚到事务起点 - 即使只读服务，如果依赖主从复制，
MyISAM在从库上遇到崩溃可能中断复制流
高并发写入场景下 MyISAM 会锁死整张表
UPDATE、DELETE、INSERT 操作在 MyISAM 中默认触发表级锁，哪怕只改一行，其他所有写请求都得排队；InnoDB 默认行级锁，只要 WHERE 条件能命中索引，就只锁匹配的行。
但注意这个坑：UPDATE user SET status = 1 WHERE name LIKE "%admin%" —— 因为 LIKE 左模糊导致索引失效，InnoDB 也会退化为锁全表，和 MyISAM 行为一致。
- 用户中心、消息队列表、实时日志表等写多读少场景，必须用
InnoDB - 如果真有高并发
SELECT COUNT(*)且无WHERE，MyISAM确实快（直接读元数据），但现实业务几乎总带条件，这时两者都要扫描 -
MyISAM的AUTO_INCREMENT在并发插入时可能重复（尤其主从环境下），InnoDB用内存+日志保证严格递增
全文搜索和只读统计类场景 MyISAM 仍有存在价值
InnoDB 直到 MySQL 5.6 才支持 FULLTEXT 索引，且功能弱于 MyISAM：不支持布尔模式中的部分运算符（如 +、-），也不支持自然语言模式下的权重微调。如果你的搜索逻辑重度依赖这些特性，MyISAM 还没完全过时。
另外，纯报表类历史表（比如每日汇总统计结果），只插入一次、后续只读，且需频繁 SELECT COUNT(*)、MIN/MAX，MyISAM 的元数据缓存确实省资源。
- 不要为了“全文搜索”把整个订单表切到
MyISAM—— 正确做法是用Elasticsearch或MySQL+InnoDB+LIKE+ 全文插件分离搜索逻辑 -
MyISAM的.MYD和.MYI文件可直接拷贝恢复，适合冷备；但热备份必须停写，InnoDB支持mysqldump --single-transaction或Percona XtraBackup在线备份
外键约束和数据完整性校验只能靠 InnoDB
MyISAM 完全无视外键语法，你写 FOREIGN KEY 它会静默忽略，不报错也不生效。这意味着父子表之间没有任何数据库层保障，全靠应用逻辑维护，极易出现孤儿记录。
InnoDB 的外键不仅检查插入/更新，还支持级联操作（ON DELETE CASCADE）、设空（ON UPDATE SET NULL），对权限、配置、组织架构类强关系模型几乎是刚需。
- 迁移旧系统时发现大量
FOREIGN KEY定义但实际无效？大概率原表是MyISAM -
ALTER TABLE ... ENGINE=InnoDB转换时，如果存在非法外键引用（比如子表有值但父表无对应主键），命令会直接失败，必须先清理数据 -
InnoDB的聚集索引结构决定了主键查询极快，但二级索引查询要回表一次；MyISAM非聚集索引查得快，但随机 IO 更高——这点在 SSD 普及后影响变小，但仍是底层差异
真正容易被忽略的是混合引擎带来的隐性成本：同一个事务里混用 InnoDB 和 MyISAM 表，MyISAM 部分无法回滚；主从复制中若从库引擎不一致，STOP SLAVE 后可能无法继续同步；还有备份策略、监控指标、慢查分析工具都得适配两套逻辑。除非有明确、不可替代的理由，否则统一用 InnoDB 是最省心的选择。
