mysql 8.0默认配置下大批量导入更慢，主因是innodb_doublewrite=on、innodb_flush_log_at_trx_commit=1与sync_binlog=1叠加导致同步i/o激增，需同时禁用双写、调为flush_log_at_trx_commit=2并绑定log_flusher线程方可提速。
innodb_flush_log_at_trx_commit=1 默认配置下，MySQL 8.0 的写入性能其实**更差**——大规模导入变慢才是常见现象。所谓“8.0 写入更快”，只在**正确调优后、特定场景下成立**，不是版本升级自动带来的红利。
为什么默认配置下 8.0 大批量写入反而更慢
根本矛盾在于：8.0 强化了持久性保障机制，但没默认配平资源调度。几个关键叠加因素直接拖慢导入速度：
-
innodb_doublewrite = ON（8.0.20+ 强制启用）：每页写入需先落盘到独立doublewrite文件，再写数据文件，多一次同步 I/O -
innodb_flush_log_at_trx_commit = 1+sync_binlog = 1（8.0 默认开启 binlog）：两阶段提交路径更重，小事务或未显式包裹的 INSERT 每条都触发 fsync - log_writer / log_flusher 线程拆分后未绑定 CPU：高并发刷日志时，
log_flusher频繁被抢占，延迟升高，事务卡在 commit 阶段
让 8.0 在大批量写入中真正快起来的关键操作
必须同时调整三项，缺一不可：
- 临时关闭双写缓冲：
SET GLOBAL innodb_doublewrite = OFF;（仅限可信环境下的离线导入，完成后务必恢复） - 放宽日志刷盘策略：
SET GLOBAL innodb_flush_log_at_trx_commit = 2;（写入 OS cache 即返回），并配套设SET GLOBAL sync_binlog = 0;或启动时加--skip-log-bin - 绑定
log_flusher线程到专用 CPU：
– 查线程 ID：SELECT THREAD_ID FROM performance_schema.threads WHERE NAME = 'log_flusher';
– 创建资源组：CREATE RESOURCE GROUP rg_log_flusher TYPE = SYSTEM VCPU = 0 THREAD_PRIORITY = -20 ENABLE;
– 立即绑定：SET RESOURCE GROUP rg_log_flusher FOR <thread_id>;</thread_id>
为什么这些操作对 5.7 不必要
5.7 没有资源组机制，log 写入是单一线程，不存在线程争抢；双写缓冲未物理分离，I/O 路径更短；binlog 默认关闭，无两阶段提交开销。它的“快”是架构轻量的结果，不是调优能力更强。
8.0 的优势不在默认行为，而在可干预深度——你得亲手把 log_flusher “钉死”，把 redo 日志文件调大到 1G 以上，把 buffer 设到 256M，否则它只是个更重、更慢的 5.7。
