MyISAM纯插入吞吐量“快”是假象，实为牺牲表级锁、一致性与崩溃恢复能力换来的，真实业务不可用；InnoDB通过调优（如禁用约束检查、优化日志刷盘、主键排序等）可大幅提升导入性能，且保障ACID与高并发读写。
MyISAM在纯插入吞吐量上“看起来”更快，但这个快是带严重副作用的假象——它用锁表、丢一致性、牺牲恢复能力换来的，真实业务中几乎不可用。
MyISAM批量导入快在哪？快得不安全
MyISAM的INSERT确实常比InnoDB快1–5倍，尤其在500万行以上场景。但这快的本质是：
- 全程表级锁：
INSERT期间整张表不可读，SELECT全排队，业务查不到最新数据 - 无事务、无redo：崩溃后
.MYD文件损坏概率高，REPAIR TABLE可能静默丢数据 - 索引更新是“懒惰式”的：先写数据再批量建索引，看似快，但导入完立刻查会触发隐式重建
- 不支持
LOAD DATA INFILE的并发加载，只能单线程灌入
InnoDB批量导入慢的根源和调优点
InnoDB默认配置下慢，不是引擎不行，而是ACID保障机制被“过度启用”了。关掉几项就能追平甚至反超：
-
SET UNIQUE_CHECKS = 0：临时关闭唯一索引校验，导入后再ANALYZE TABLE -
SET FOREIGN_KEY_CHECKS = 0：跨表导入时避免逐行外键检查 - 调低
innodb_flush_log_at_trx_commit：从1→2（日志刷盘异步）或仅导入期设为0（风险可控） - 确保源数据按主键
ORDER BY id排序：减少页分裂，写入效率可提升30%+ - 增大
innodb_buffer_pool_size：至少占物理内存70%，避免频繁换页
真正决定耗时的是导入方式，不是引擎
同一张InnoDB表，不同导入路径性能差5倍以上：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
mysqldump + mysql：默认单线程+每千行自动提交 → 最慢，100GB常超6小时 -
mydumper/myloader -t 16：并行导出导入+自动禁用索引检查 → 1.5–2.5小时 -
LOAD DATA INFILE（配合前述调参）→ 40–70分钟，这才是生产首选
而MyISAM连myloader都不支持，更没法用LOAD DATA INFILE做并行加载——它的“快”，只存在于单线程、小数据、无并发查询的真空环境里。
别只算导入时间，算算后续代价
导入只是开始。接下来的查询、更新、高并发访问，才是长期瓶颈：
- MyISAM崩溃后无法自动恢复，
REPAIR TABLE失败就得从备份拉——你的备份有多新？ - MyISAM表级锁让
INSERT和SELECT互斥，高峰期页面白屏不是错觉 - InnoDB的MVCC让长查询不阻塞写入，写入也不拖垮读请求，这才是在线服务的基本盘
真正该纠结的不是“哪个引擎导入快”，而是“导入后这张表要怎么用”。如果只是临时中转表、离线计算用，MyISAM勉强能用；但只要涉及线上读写、事务、可靠性，InnoDB就是唯一合理选择——它的“慢”，是为后面几个月稳定运行提前付的保费。
