MySQL写入压力主要卡在日志刷盘行为；InnoDB依赖redo log WAL机制，刷盘频率由innodb_flush_log_at_trx_commit控制（1最安全最慢、0最快但丢数据、2折中），而MyISAM直写数据文件，无事务保障且并发差。
MySQL写入压力主要卡在哪儿？看日志刷盘行为
磁盘写入压力不只看“写了多少数据”，更关键的是“什么时候写、怎么写”。InnoDB 和 MyISAM 的根本差异就在这里：前者靠 redo log 做预写日志（WAL），后者直接改数据文件。这意味着即使写入量相同，InnoDB 可能批量刷日志、延迟落盘，而 MyISAM 是每条 INSERT 或 UPDATE 都可能触发一次或多次数据页写入。
innodb_flush_log_at_trx_commit 怎么设才不拖慢写入？
这个配置直接决定 InnoDB 日志刷盘频率，是写入性能和崩溃安全的平衡点。它不是“开/关”开关，而是三种行为模式：
-
1：每次事务提交都调用fsync()刷ib_logfile到磁盘 → 安全但最慢，尤其在机械盘或高并发小事务场景下，IOPS 瓶颈明显 -
0：每秒刷一次日志，事务提交只写内存 → 快，但崩溃最多丢 1 秒数据 -
2：每次提交写 OS cache，不强制fsync→ 折中，依赖 OS 稳定性，断电可能丢数据，但比1快数倍
注意：sync_binlog 如果也设为 1，且启用了 binlog，那么每次事务实际要刷两次磁盘（redo + binlog），压力翻倍。线上 OLTP 系统若对一致性要求不高，innodb_flush_log_at_trx_commit=2 + sync_binlog=1000 是常见压测调优组合。
MyISAM 写入为什么看起来“快”，实则更危险？
MyISAM 没有 WAL，更新直接写 .MYD 文件，索引更新写 .MYI。它所谓“快”，是因为省掉了日志序列化和刷盘协调逻辑，但代价是：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 表级锁导致并发写入串行化，
INSERT多时容易卡住其他操作 - 崩溃后无法保证数据页和索引页一致，
REPAIR TABLE不一定成功，myisamchk --recover也可能丢数据 - 没有真正的事务，
INSERT ... SELECT或批量导入中途失败，无法回滚，残留脏数据难清理
另外，MyISAM 的 DELAY_KEY_WRITE=1 虽能缓存索引更新，但仅作用于 .MYI，数据文件仍实时写，且该选项在 MySQL 8.0 中已被移除。
如何判断当前写入瓶颈真正在日志还是数据文件？
别猜，看指标。关键观察项只有三个：
- 检查
SHOW ENGINE INNODB STATUS输出里的Log sequence number和Last checkpoint at差值 —— 差值持续 > 1GB，说明日志刷盘跟不上，innodb_log_file_size可能太小 - 用
iostat -x 1看%util和await，如果sda（或对应磁盘）的await经常 > 10ms，且w/s高，再结合pt-ioprofile确认是不是ib_logfile*在高频刷盘 - 对比
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written'（日志字节数）和'Innodb_data_written'（数据文件字节数）—— 若前者是后者的 3~5 倍以上，说明 WAL 放大效应显著，日志 I/O 是主因
真实线上环境里，很多人调大 innodb_log_file_size 却忘了重启生效，或者改了 innodb_flush_log_at_trx_commit 却没配合调整 innodb_io_capacity，结果刷盘线程依然堵在后台。这些细节不验证，压测数据就不可信。
