随机写多应选InnoDB而非MyISAM：MyISAM表级锁导致高iowait%和I/O雪崩，InnoDB通过日志顺序写、行锁与MVCC实现可控I/O与高并发写入。
磁盘I/O模式决定引擎选型：随机写多就别碰MyISAM
MyISAM在高并发写入时会触发大量表级锁等待，导致write stall和fsync堆积，I/O等待时间飙升；InnoDB虽有事务日志刷盘开销，但通过innodb_log_file_size和innodb_flush_log_at_trx_commit可调优吞吐与持久性平衡。真实线上压测显示：当QPS写入超200且含UPDATE时，MyISAM的iowait%常突破40%，而InnoDB稳定在15%以内。
- MyISAM写操作必须同步更新
.MYD和.MYI两个文件，每次INSERT/UPDATE都引发至少两次随机I/O - InnoDB将变更先写入顺序型
ib_logfile*，再异步刷脏页到ibdata1或独立表空间，I/O更可控 - 若业务存在突发写峰值（如秒杀扣库存），MyISAM极易因锁表造成I/O队列雪崩，InnoDB的MVCC+行锁能缓冲压力
全表扫描场景下MyISAM的I/O优势已基本失效
过去认为MyISAM因数据文件紧凑、无事务头开销，全表扫描更快——这在机械硬盘+小数据集（SELECT COUNT(*) FROM table这类操作，MyISAM虽快，但代价是牺牲了崩溃一致性：一旦mysqld异常退出，.MYD和.MYI可能不一致，后续SELECT会报Incorrect key file for table错误，触发强制REPAIR TABLE，反而引发更大I/O风暴。
- MyISAM的
COUNT(*)快，是因为它把行数缓存在内存元数据里，但这个值在崩溃后不可信 - InnoDB的
COUNT(*)慢，但结果始终反映真实已提交数据，避免因统计误差导致应用逻辑错判 - SSD随机读性能已接近顺序读，MyISAM“数据文件连续”的物理优势被大幅削弱
混合读写负载下InnoDB的I/O调度更友好
MyISAM的表级锁机制会让一个慢查询（如SELECT ... WHERE text_column LIKE '%xxx%'）阻塞所有后续写入，I/O请求在内核队列中排队，await指标持续走高；InnoDB则允许读写并行，即使某行被UPDATE锁定，其他行仍可被SELECT访问，I/O请求分散更均匀。关键参数innodb_io_capacity和innodb_io_capacity_max可直接绑定到SSD的IOPS能力，让刷新脏页节奏匹配硬件极限。
- MyISAM无I/O限流机制，突发负载易打满磁盘带宽，影响同实例其他库表
- InnoDB支持
innodb_adaptive_flushing动态调节刷脏页频率，避免I/O毛刺 - 若使用云数据库（如AWS RDS、阿里云RDS），底层存储已做I/O隔离，MyISAM的“轻量”反而失去意义
唯一还值得考虑MyISAM I/O特性的场景：只读归档表 + 无崩溃恢复要求
仅当满足全部以下条件时，MyISAM的I/O行为才可能带来净收益：INSERT一次性导入后永不修改、表体积超100GB、查询以WHERE id = ?主键点查为主、且可接受mysqld崩溃后手动myisamchk修复——这种场景2026年现实中极少，多数已被ARCHIVE引擎或外部列存（如ClickHouse）替代。MySQL 8.4已标记myisam_recover_options为废弃配置项，官方明确提示“仅用于兼容遗留系统”。
- MyISAM的
.MYI索引文件支持COMPRESSED选项，但压缩后无法在线修改，I/O节省被运维复杂度抵消 - InnoDB的
ROW_FORMAT=COMPRESSED支持实时增删改，且压缩率通常更高（zlib vs myisampack） - 真正影响I/O负载的从来不是引擎名字，而是
buffer_pool_size是否足够、read_buffer_size是否合理、以及SQL是否命中索引
iostat -x 1输出里的r_await、w_await和%util，而不是引擎名。 
