必须选择InnoDB，因其支持事务、行锁、崩溃恢复等关键特性；MyISAM虽在批量导入时看似更快，实则因阉割一致性保障而牺牲可靠性，且无法应对真实业务中的并发读写与后续维护需求。
MyISAM 在 LOAD DATA INFILE 或批量 INSERT 时“看起来快”，但这不是性能优势，而是功能阉割后的副作用。真实业务里，导入只是开始，后续的查询、更新、高并发访问、崩溃恢复，才是长期瓶颈所在。
MyISAM 单线程导入快，但代价是什么？
它快，是因为跳过了所有保障数据一致性的环节：
-
innodb_flush_log_at_trx_commit这类日志刷盘逻辑根本不存在 → 没有 redo log 写入开销 - 表级锁 → 不用管理行锁、MVCC 版本链、间隙锁等复杂结构
- 不校验唯一索引、外键、约束 → 插入前不做任何检查
- 索引与数据分离 → 插入只需追加 MYD 文件 + 更新 MYI 文件，无聚簇索引页分裂
这些省略项，在 InnoDB 里是必须付出的成本 —— 但也是你线上系统能活下来的基础。一旦导入后要查、要改、要连主从、要 crash-safe，MyISAM 立刻崩盘。
InnoDB 批量导入慢？其实是默认配置没对齐场景
InnoDB 不慢，是默认配置太“保守”。批量导入时临时调优，效果立竿见影：
- 导入前执行：
SET innodb_flush_log_at_trx_commit = 2（或0，仅限导入期间）→ 避免每次事务都刷盘 -
SET UNIQUE_CHECKS = 0和SET FOREIGN_KEY_CHECKS = 0→ 关闭约束校验，导入完再ANALYZE TABLE - 确保源数据按主键排序（如
ORDER BY id）→ 减少 B+Tree 页分裂，提升写入效率 30%+ -
innodb_buffer_pool_size至少设为待导入数据量的 50% → 避免频繁换页拖慢速度
这些调整叠加后，InnoDB 的批量导入速度常可逼近甚至反超 MyISAM，同时保留事务、行锁、崩溃恢复能力。
别只盯着 INSERT 速度，真正致命的是后续行为
导入完成后的实际使用，才是分水岭：
- MyISAM 崩溃后需手动
REPAIR TABLE，可能丢数据；InnoDB 自动 recovery，重启即恢复一致状态 - MyISAM 表级锁 → 一个
INSERT就堵住所有SELECT；InnoDB 行锁 → 查写互不干扰 - MyISAM 的
COUNT(*)快，但结果是“表级缓存值”，不反映事务隔离级别下的真实可见行数；InnoDB 的慢，恰恰是语义正确 - MyISAM 不支持 MVCC → 长事务下
SELECT可能被阻塞；InnoDB 快照读天然规避此问题
现代 MySQL（8.0.36+）已默认禁用 MyISAM 的自动启用，云厂商（如阿里云 RDS、AWS RDS）也逐步限制其创建权限 —— 不是因为它不能用，而是因为它太容易被误用。
真正容易被忽略的点：很多人以为“我只导入一次，之后只读”，但只要业务上线，就不可能永远只读。哪怕后台导出报表、定时统计、管理员查日志，都会触发并发读写。这时候 MyISAM 的表锁和无事务特性，会成为第一个爆掉的点。
