必须用InnoDB，因MyISAM无事务机制，无法保证多操作原子性；事务失败时InnoDB可回滚至一致状态，MyISAM则遗留脏数据。
只要业务里有“多个操作必须一起成功或一起失败”的逻辑，就必须用 InnoDB，MyISAM 在这类场景下不是慢，是根本不能用。
事务失败时数据状态是否可控
这是最直接的判断依据。比如订单创建+库存扣减+日志写入这三步，如果第二步失败，InnoDB 能靠 ROLLBACK 把前两步全撤回；MyISAM 没有事务日志，执行到哪崩到哪，可能留下已创建订单但库存没扣、或库存已扣但订单没建的脏数据。
常见错误现象：
- 应用层 try-catch 后手动“补偿”，但网络超时、进程崩溃等场景下补偿逻辑本身不可靠
- 主从复制中，
MyISAM表在从库崩溃后可能中断 SQL 线程，需人工REPAIR TABLE，期间无法同步
并发写入时锁粒度是否影响业务吞吐
InnoDB 默认行级锁，但前提是 WHERE 条件能命中索引；MyISAM 一律表级锁，哪怕只 UPDATE 一行，整张表其他读写全被堵住。
使用场景举例：
- 用户中心表频繁更新
last_login_time：用InnoDB+ 主键或唯一索引 WHERE，锁只落在目标行 - 消息队列表按
status批量消费：若WHERE status = 0无索引，InnoDB会退化为全表扫描+全表锁，和MyISAM行为一致——这时问题不在引擎，而在索引缺失
崩溃后能否自动恢复而不丢数据
InnoDB 依赖 ib_logfile0（重做日志）+ 双写缓冲，在 mysqld 异常终止后重启时自动前滚未刷盘的变更、回滚未提交事务，整个过程无需人工干预；MyISAM 崩溃后 .MYD 文件极易损坏，必须运行 REPAIR TABLE，且该命令本身可能失败或静默丢失数据。
性能与兼容性影响：
-
InnoDB的崩溃恢复时间基本恒定（秒级），与数据量无关；MyISAM的REPAIR时间随表大小线性增长，TB 级别可能耗时数小时 - MySQL 5.7+ 默认禁用
MyISAM的REPAIR功能，需显式开启myisam_recover_options，否则直接报错退出
全文搜索需求是否真需要 MyISAM
如果你的搜索逻辑依赖 +/- 布尔运算符、自然语言模式下的词频加权，且无法接受 Elasticsearch 或 LIKE %keyword% 的性能折损，那 MyISAM 的 FULLTEXT 确实还有存在价值。但注意：
- 不要把订单表、用户表这种核心业务表切到
MyISAM只为支持全文搜索——应该拆出单独的search_index表，或用外部搜索引擎 - MySQL 8.0 的
InnoDB已支持全部布尔语法，且可配合ngram插件处理中文分词，MyISAM的优势正在快速收窄
真正容易被忽略的是：事务隔离级别和 MVCC 对查询结果的影响。即使你只读不写，InnoDB 的 SELECT 默认走快照读（避免加锁），而 MyISAM 是当前读，高并发下可能看到不一致的中间态数据——这点在报表统计类场景中常被误判为“MyISAM 更准”，实际是语义不同。
