MySQL 8.0 默认写入性能低于5.7,主因是log_writer与log_flusher线程拆分后争抢CPU资源,且未启用Resource Group约束其优先级与CPU绑定;需手动创建SYSTEM资源组绑定log_flusher、调大redo日志参数并确保MySQL进程具备CAP_SYS_NICE权限。

MySQL 8.0 并不天然比 5.7 性能更好——写入性能在默认配置下反而更差,必须手动调优才能释放优势。 这个反直觉结论源于两个关键变化:一是 log_writer 和 log_flusher 线程被拆分,导致 CPU 调度竞争加剧;二是资源组(Resource Group)机制虽已就位,但默认未启用,无法约束这些关键线程的优先级与 CPU 绑定。
log_writer 和 log_flusher 拆分后为什么变慢了
MySQL 8.0 将原本由单一线程承担的日志写入职责,拆成了两个独立线程:log_writer(负责把日志从 buffer 写入 OS 缓存)和 log_flusher(负责将 OS 缓存中的日志刷到磁盘)。这个设计本意是提升并发吞吐,但问题出在调度上:
- 这两个线程默认都跑在普通用户优先级,和大量用户连接线程、InnoDB 后台线程一起争抢 CPU 时间片
- 尤其在高并发小事务场景(如
innodb_flush_log_at_trx_commit = 1),log_flusher频繁唤醒却常被抢占,导致日志刷盘延迟升高、事务提交阻塞 - 对比 5.7 的单线程模型,8.0 的“拆分”反而放大了调度开销,压测中常见
log_flusher的os_waits指标飙升
用 Resource Group 把 log_flusher 线程“钉死”在指定 CPU 核
MySQL 8.0 的 Resource Group 是唯一能直接干预线程级 CPU 分配的原生机制。对 log_flusher 这类延迟敏感线程,必须显式绑定:
- 先查出线程 ID:
SELECT THREAD_ID, NAME, TYPE FROM performance_schema.threads WHERE NAME LIKE '%log_flusher%'; - 创建专用 SYSTEM 类型资源组,限定 vcpu 范围并设高优先级:
CREATE RESOURCE GROUP rg_log_flusher TYPE = SYSTEM VCPU = 0-1 THREAD_PRIORITY = -20 ENABLE; - 立即绑定:
SET RESOURCE GROUP rg_log_flusher FOR <thread_id>; - 注意:SYSTEM 类型资源组仅允许绑定 MySQL 内部线程(如
log_flusher、purge_thread),不能用于用户会话
innodb_log_file_size 和 innodb_log_buffer_size 必须同步调大
即使绑定了资源组,如果日志缓冲区太小或文件轮转太频繁,log_writer 仍会高频触发 flush,抵消 CPU 绑定效果:
-
innodb_log_file_size建议设为 1G~2G(而非默认 48M),大幅降低 checkpoint 频率和 log file 切换开销 -
innodb_log_buffer_size至少 64M,避免大事务中途溢出写盘;若业务含批量更新,可设至 256M - 修改这两项需停库重启,且首次启动会自动重建 redo log 文件——务必提前备份
- 不要只调大
innodb_log_file_size却忽略innodb_log_files_in_group,默认值 2 是合理起点,无需改动
innodb_flush_log_at_trx_commit=2 不是万能解药
很多人直接改成 innodb_flush_log_at_trx_commit = 2 来“提速”,但这只是掩盖问题,且带来数据风险:
- 它让
log_writer只写入 OS 缓存,再靠后台每秒一次的log_flusher刷盘——若此时log_flusher因调度失灵而延迟,OS 缓存里的日志就卡住了 - 真正瓶颈不在“要不要刷”,而在“能不能准时刷”。没做资源组绑定前,
=2可能比=1更慢 - 生产环境若必须用
=2,请确保log_flusher已绑定高优先级资源组,并监控innodb_os_log_pending_fsyncs是否持续 > 0
最易被忽略的一点:Resource Group 的 THREAD_PRIORITY 在 Linux 上实际映射为 sched_priority,而 MySQL 进程本身需有 CAP_SYS_NICE 能力(通常要 setcap cap_sys_nice+ep /usr/sbin/mysqld),否则优先级设置静默失效——不报错,但不起作用。



















