InnoDB是唯一合理选择，MyISAM功能残缺、风险不可控且2026年已默认禁用；它不支持事务、崩溃恢复不可靠、表级锁严重制约并发，而InnoDB通过redo/undo log保障原子性、行级锁与自动恢复确保数据一致与高可用。
InnoDB 是绝大多数业务场景下唯一合理的选择；MyISAM 不是“读快一点”的替代方案，而是功能残缺、风险不可控的遗留组件——它在 2026 年已默认禁用，且连 REPAIR TABLE 都可能丢数据。
事务一致性要求一出现，MyISAM 就直接出局
只要你的业务涉及“多个操作必须全成功或全失败”，比如订单创建+库存扣减+日志记录，InnoDB 就不是可选项，而是强制项。
-
MyISAM对BEGIN/COMMIT/ROLLBACK完全无视：语句一执行就落盘，中途崩溃 = 半截脏数据留在表里 -
InnoDB依赖redo log和undo log实现原子性：转账失败时，UPDATE自动回滚，余额不会只扣不转 - 批量导入（如
INSERT ... SELECT）中断后，MyISAM留下部分写入的损坏状态；InnoDB可回滚到事务起点，无需人工干预
UPDATE/DELETE 带条件时，MyISAM 锁整张表，InnoDB 只锁匹配行
高并发写入场景下，MyISAM 的表级锁会成为系统瓶颈，哪怕你只改一行。
-
UPDATE users SET status=1 WHERE id=123：在InnoDB中只锁这一行；MyISAM则锁住整个users表，后续所有读写全部排队 - 后台定时任务跑
INSERT INTO log_table，若表上有实时查询，MyISAM会卡住整个页面加载 - 注意陷阱：
WHERE name LIKE "%admin%"因左模糊导致索引失效，InnoDB也会退化为全表扫描+行锁（不是表锁），但至少不阻塞其他无关行的更新
COUNT(*) 快 ≠ 实际快，MyISAM 的“快”是假象
MyISAM 的 COUNT(*) 快，是因为它缓存了行数变量；但这结果不满足事务隔离语义，且带 WHERE 条件时两者都要走索引扫描。
-
SELECT COUNT(*) FROM orders WHERE status = 'paid'：无论引擎，都需按索引过滤可见行，性能差异可忽略 -
MyISAM的缓存值在并发写入时可能不准（尤其主从复制下），而InnoDB每次返回的是当前事务视角下真实可见的行数 - 现实业务几乎从不执行无条件
COUNT(*)；真有这种需求，也建议用单独计数表或 Redis 缓存，而不是靠引擎“作弊”
崩溃恢复不是“能不能修”，而是“要不要停服手动修”
服务器断电或进程异常退出后，InnoDB 启动时自动重放 redo log，秒级恢复；MyISAM 需人工介入，且过程不可靠。
-
MyISAM损坏后必须运行REPAIR TABLE，该命令可能丢数据；更严重的损坏需停服使用myisamchk，期间表完全不可用 -
InnoDB的崩溃恢复全自动，DBA 无需干预；ib_logfile0和undo logs共同保障一致性 - 2026 年多数发行版（如 Percona Server 9.6、MySQL Community 9.6.0）已默认禁用
MyISAM插件，新建库中甚至无法创建MyISAM表
真正容易被忽略的点在于：存储引擎不是性能调优项，而是数据语义边界。
选错不是慢一点，而是资金对不上、订单丢了、权限同步失败——这些故障不会报错，只会静默污染数据。
