myisam写入卡死源于表级锁机制，单个insert/update即锁全表，导致读写排队；innodb写入慢多因默认强一致性配置未适配场景，如innodb_flush_log_at_trx_commit=1、约束校验开启、主键无序及缓冲池过小等。
MyISAM写入卡死是因为表级锁
只要有一个INSERT或UPDATE在执行，整张MyISAM表就进入Locked状态，后续所有读写都排队——SHOW PROCESSLIST里能看到大量Locked或Waiting for table level lock。这不是并发不够，而是设计如此：它没有行锁、没有MVCC、不维护事务日志，省下的开销全换成了“一写全堵”。
常见误判是看到CPU和磁盘IO不高就以为系统空闲，其实线程全卡在锁等待上。压测时若只跑单线程INSERT，MyISAM确实快2–3倍；但一旦并发写入超过50 QPS，锁队列就开始堆积，QPS反而断崖下跌。
InnoDB写入慢常因配置没对齐场景
InnoDB默认配置面向强一致性，不是为批量导入优化的。真正拖慢写入的往往不是引擎本身，而是这些默认项：
-
innodb_flush_log_at_trx_commit = 1：每次事务都刷盘，I/O变成瓶颈 → 导入时可临时设为2 -
UNIQUE_CHECKS = 1和FOREIGN_KEY_CHECKS = 1：每行都校验约束 → 批量前执行SET UNIQUE_CHECKS = 0和SET FOREIGN_KEY_CHECKS = 0 - 主键无序（如UUID）：导致频繁页分裂 → 源数据提前
ORDER BY id再LOAD DATA INFILE -
innodb_buffer_pool_size太小：缓冲池不足，写入被迫频繁刷脏页 → 至少设为物理内存的50%
聚簇索引让InnoDB写入更可控
InnoDB把数据按主键物理排序存储，只要主键是自增整型，新记录就顺序追加到B+树末尾，避免随机写和页分裂。而MyISAM索引与数据分离，插入时看似简单，但所有写操作都得争抢同一把表锁，无法并行。
典型反例：SELECT * FROM t WHERE created_at > '2024-01-01'在InnoDB中变慢，往往不是引擎问题，而是主键设计不当（比如用UUID），导致优化器放弃走索引，退化为全表扫描。此时调优重点不是换引擎，而是重建主键或加覆盖索引。
崩溃恢复能力直接影响写入策略选择
MyISAM不记事务日志，INSERT中途断电=数据可能损坏，且REPAIR TABLE不一定能找回；InnoDB靠redo log保证crash-safe，哪怕写到一半掉电，重启后也能自动恢复。这意味着：如果你需要在线服务、不能接受停机修复，InnoDB的“稍慢”其实是可控成本，而MyISAM的“快”是透支稳定性的赌注。
最容易被忽略的一点：混合引擎库中，只要有一张MyISAM表，mysqldump --single-transaction就失效，整个备份过程会触发全局读锁——这点在业务高峰期极易引发雪崩。
