为什么 InnoDB 的 insert 变慢了？先看事务和日志机制
InnoDB 写入性能卡顿，八成不是磁盘或 CPU 问题，而是被
redo log刷盘、
flush_log_at_trx_commit配置、或者唯一约束校验拖住的。每次
INSERT实际要走：写内存 buffer → 记 redo 日志 →（可能）刷盘 → 提交事务 →（可能）更新二级索引页 →（可能）刷脏页。其中任意一环同步阻塞，吞吐就掉下来。
实操建议：
确认是否在高频小事务场景下用了flush_log_at_trx_commit = 1（默认值），它强制每次 commit 都 fsync
redo log，是写入瓶颈主因；可临时调为
2（仅 write 到 OS cache）或
0（每秒刷一次），但需接受最多 1 秒事务丢失风险 避免在写入密集表上建过多二级索引，每个
INSERT都要维护所有索引树，尤其
UNIQUE约束会触发额外的唯一性查找 批量插入时，务必用
INSERT INTO ... VALUES (...), (...), (...)而非多条单行
INSERT，减少事务开销和日志写入次数
bulk insert 时怎么让 InnoDB 不卡住？
大批量导入（如千万级 CSV 导入）若按默认配置执行，极易触发
innodb_buffer_pool压力、
redo log切换频繁、甚至
lock wait timeout。关键不是“加速”，而是“降压”和“分片”。
实操建议：
导入前执行SET autocommit = 0，显式用
BEGIN; ... COMMIT;包裹每 5000–10000 行，避免单事务过大导致 undo log 膨胀和锁持有过久 临时调大
innodb_log_file_size（需重启）和
innodb_log_buffer_size，减少 redo log 切换与刷新频率 导入期间关闭唯一检查：
SET unique_checks = 0；关闭外键检查：
SET foreign_key_checks = 0（导入后记得恢复） 用
LOAD DATA INFILE替代
INSERT，它绕过 SQL 解析层，直接走存储引擎加载路径，快 5–10 倍；注意文件需在 MySQL 服务端且权限正确
MyISAM 还能用来提速写入吗？
MyISAM 在纯追加写（无并发更新、无事务）场景下，确实比 InnoDB 快——因为它没有事务日志、无行锁、索引更新异步。但代价极高：崩溃后数据易损坏、并发写入只能表锁、不支持 ACID。2024 年新项目基本不该考虑。
实操建议：
仅限离线 ETL 中间表、日志归档表等“写一次、读多次、不关心崩溃一致性”的场景，且必须配合DELAY_KEY_WRITE = 1（延迟更新索引到磁盘） 绝对不要在 MyISAM 表上做
UPDATE或高并发
INSERT，表锁会让后续所有写请求排队 MySQL 8.0+ 已移除 MyISAM 系统表支持，部分运维工具（如
mysql_upgrade）不再兼容，长期维护成本陡增
真正影响写入上限的三个隐藏参数
很多调优只盯着
innodb_buffer_pool_size，其实下面三个参数在高并发写入时更敏感，且容易被忽略。
实操建议：
innodb_io_capacity和
innodb_io_capacity_max：控制后台刷脏页速率。SSD 上建议设为磁盘 IOPS 的 50%~70%，比如 NVMe 卡标称 50K IOPS，可设
innodb_io_capacity = 25000；设太低会导致 buffer pool 脏页堆积，最终阻塞新写入
innodb_max_dirty_pages_pct：脏页占比阈值（默认 75%）。若写入持续高于刷盘能力，该值会被频繁触达，引发紧急刷脏行为，造成写入毛刺；可适当降到
60让刷盘更平滑
innodb_adaptive_flushing：必须开启（默认 ON），否则 InnoDB 不会根据 redo log 生成速度动态调整刷脏节奏，容易在 burst 写入后集体卡顿
写入优化不是堆参数，而是理解每条
INSERT背后发生了多少次磁盘寻道、多少次内存拷贝、多少次锁竞争。最常被忽略的，其实是应用层的事务粒度和批量策略——再好的引擎也扛不住每秒几千个单行 auto-commit。
