mysql 8.0逻辑备份变慢的核心原因是默认启用innodb_doublewrite、performance_schema全开及事务性数据字典初始化，导致单表扫描和元数据获取延迟增加；优化需临时关闭performance_schema采集、禁用doublewrite、调大buffer pool并合理使用dump参数。
MySQL 8.0 的逻辑备份（如 mysqldump 或 mydumper）在默认配置下普遍比 5.7 慢，核心原因不是备份工具变了，而是 8.0 默认启用的几项持久化与安全机制，在逻辑读场景下叠加了额外同步 I/O 和元数据开销。
为什么 mysqldump 在 8.0 上变慢了
逻辑备份本质是“反复执行 SELECT”，所以性能瓶颈不在磁盘吞吐，而在服务端对每个查询的响应延迟。8.0 默认开启的以下三项，会显著拖慢单表扫描和元数据获取速度：
-
innodb_doublewrite = ON：即使只是读取数据，InnoDB 在某些页加载路径中仍需校验 doublewrite buffer 元数据（尤其当 buffer pool miss 高时），增加 CPU 和内存访问开销 -
performance_schema默认全开：8.0 的 events_statements_history_long、events_waits_history_long 等 consumer 默认 ENABLED，每次SELECT都触发采集逻辑，实测可使mysqldump单表耗时增加 15%~40% - 事务性数据字典虽快，但首次访问表时仍需 MVCC 快照初始化：相比 5.7 直接读
.frm文件，8.0 要走mysql.innodb_table_stats+mysql.columns_priv等多表 JOIN，若统计信息未预热或权限复杂，延迟更明显
优化 mysqldump 备份速度的关键操作
不改备份命令本身，只调服务端状态，就能恢复到接近 5.7 的速度：
- 临时关闭 performance_schema 采集：
UPDATE performance_schema.setup_consumers SET ENABLED = 'NO' WHERE NAME LIKE 'events_statements_%' OR NAME LIKE 'events_waits_%';（注意：必须用UPDATE，SET GLOBAL不生效） - 禁用 doublewrite（仅限备份期间）：
SET GLOBAL innodb_doublewrite = OFF;—— 不影响数据一致性，因逻辑备份不写盘；备份完立即设回ON - 确保
innodb_buffer_pool_size足够大，让整张表能常驻内存；若 dump 多表，加--skip-opt --skip-extended-insert减少客户端解析压力 - 避免
--single-transaction与--lock-tables混用：8.0 下前者会隐式开启READ COMMITTED隔离，若遇到长事务或大表，MVCC 版本链扫描可能卡住；优先用--single-transaction+--skip-lock-tables
mydumper 备份慢的特殊原因与对策
mydumper 是多线程逻辑备份工具，它在 8.0 上慢得更明显，问题出在线程级资源争抢：
- 8.0 默认未绑定
log_flusher线程，而mydumper的高并发 SELECT 会高频触发innodb_log_buffer_size溢出，间接唤醒log_flusher，导致其与 worker 线程争 CPU - 解决方法不是降并发数，而是提前约束关键线程：
CREATE RESOURCE GROUP rg_dump TYPE = SYSTEM VCPU = 2 THREAD_PRIORITY = -15 ENABLE;，再用SET RESOURCE GROUP rg_dump FOR <thread_id>;</thread_id>绑定mydumper进程内所有 MySQL 连接线程（查performance_schema.threads获取 ID） - 同时设
innodb_log_buffer_size = 256M，大幅减少 flush 触发频率，削弱 log_flusher 调度压力
真正影响逻辑备份速度的，从来不是“版本新旧”，而是你有没有关掉那些为写入安全设计、却在只读场景下白跑的机制。尤其要注意 performance_schema 的 consumer 开关——它不像变量能 SET SESSION，必须显式 UPDATE 才生效，这点极易被忽略。
