InnoDB比MyISAM更稳因采用行级锁与事务日志，而MyISAM依赖表级锁与堆式写入；高并发写时MyISAM整表锁定阻塞所有操作，InnoDB仅锁涉及行，其余查询写入不受影响。
高并发写入时 InnoDB 为什么比 MyISAM 更稳
因为 InnoDB 用行级锁 + 事务日志，MyISAM 是表级锁 + 堆式写入。一有写操作，整个 MyISAM 表就卡住，连 SELECT 都排队；而 InnoDB 只锁被改的几行，其他查询和写入照常。
实操建议：
- 压测时用
sysbench模拟多线程UPDATE，别只跑SELECT——MyISAM在纯读场景下反而略快，但这不是真实负载 - 开启
innodb_flush_log_at_trx_commit=1保证崩溃安全，但会拖慢写入；若允许丢少量事务，可设为2，性能提升明显 -
MyISAM的DELAY_KEY_WRITE=1能缓解索引写压力，但机器断电就可能索引损坏，线上慎开
SHOW PROCESSLIST 里大量 Locked 状态，大概率是 MyISAM
这是最直接的线索：MyISAM 表在写入或修索引时，所有后续语句都会卡在 Locked 状态；而 InnoDB 卡住时显示的是 updating、waiting for table metadata lock 或具体行锁等待。
常见错误现象：
- 执行
ALTER TABLE后，其他查询全挂起，SHOW PROCESSLIST里一堆Locked - 一个慢
INSERT ... SELECT就让整张MyISAM表不可用 -
REPAIR TABLE过程中，表完全不可读 ——InnoDB不需要这种操作
key_buffer_size 和 innodb_buffer_pool_size 别混着调
两个参数作用对象完全不同：key_buffer_size 只给 MyISAM 的索引缓存用，对 InnoDB 完全无效；innodb_buffer_pool_size 才是 InnoDB 的核心内存区，缓存数据页+索引页。
容易踩的坑：
- 把
MyISAM的key_buffer_size设得过大（比如占物理内存 50%），反而挤占系统可用内存，导致频繁 swap - 混合引擎库中，
innodb_buffer_pool_size设太小（如默认的 128M），InnoDB表全走磁盘，性能断崖下跌 -
MyISAM没有“缓冲池”概念，它的数据页不缓存，所以key_buffer_size再大也加速不了SELECT *类全表扫描
备份时 mysqldump 加 --single-transaction 对 MyISAM 无效
这个参数本质是靠 START TRANSACTION WITH CONSISTENT SNAPSHOT 实现一致性快照，仅 InnoDB 支持；MyISAM 备份时仍会锁表，哪怕加了该参数也没用，mysqldump 会自动退化为 FLUSH TABLES WITH READ LOCK。
使用场景提醒：
- 混合引擎库 dump，只要含
MyISAM表，整个备份过程就存在全局读锁，业务写入中断 -
Percona XtraBackup也只支持InnoDB热备，MyISAM部分仍需锁表 - 想避免锁表？唯一办法是提前把
MyISAM表迁成InnoDB，注意检查FULLTEXT索引和AUTO_INCREMENT行为差异
真正麻烦的不是性能数字，而是两种引擎对“并发”“一致”“恢复”的定义根本不同——MyISAM 的“快”，建立在放弃事务、锁粒度和崩溃恢复的基础上，这些代价在高负载下会突然具象成锁表、丢数据、备份失败。
