mysqldump在高并发下会卡住写入，因其--single-transaction开启长事务导致purge线程无法清理undo，引发history list暴涨、SELECT变慢及备份失败；应优先选用xtrabackup物理备份。

高并发下直接用 mysqldump 备份，大概率会卡住写入，不是因为备份慢，而是 purge 线程被拖垮后引发连锁反应——SELECT 变慢、history list length 暴涨、undo 表空间膨胀，最终让备份本身也失败。

为什么 mysqldump 会触发 purge 压力？

mysqldump 加 --single-transaction 时，会开启一个长事务来保证一致性快照。这个事务的 trx_started 时间会一直延续到 dump 结束。而 InnoDB 的 purge 线程不能清理任何被活跃事务依赖的 undo 记录——哪怕这个事务只是空闲连接没做任何操作。

常见错误现象：

• SHOW ENGINE INNODB STATUS\G 里 HISTORY LIST LENGTH 在 dump 过程中猛涨（比如从 5000 跳到 80000）
• dump 进程本身变慢，SHOW PROCESSLIST 显示它卡在 Waiting for table flush 或 Sending data
• 业务 SELECT 响应时间明显波动，尤其主键点查（SELECT * FROM t WHERE id = ?）延迟升高

innodb_purge_threads 不是“调大就完事”

盲目把 innodb_purge_threads 设成 8 或 16，反而会让问题更糟：线程间争抢 purge_sys->mutex，挤占 buffer pool 刷脏页资源，甚至导致 purge 效率不升反降。

实操建议：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 纯读场景或低频更新库，保持默认 innodb_purge_threads = 1 即可
• 写密集场景（如高频 DELETE/UPDATE），设为 2～4；超过 4 需谨慎验证
• 必须同步调整 innodb_purge_batch_size：从默认 300 提到 500～1000，但别超 2000
• 动态修改后不会立刻生效：SET GLOBAL innodb_purge_threads = 4 只影响下一次 purge 循环启动的新线程，旧线程会跑完当前 batch 才退出

备份前必须检查的三项关键指标

别等 mysqldump 开始了才发现问题。执行前快速确认：

• 查长事务：SELECT trx_id, trx_started, trx_state FROM information_schema.INNODB_TRX ORDER BY trx_started LIMIT 5；若有运行超 30 秒的空闲事务，先 kill 掉
• 看历史链长度：SHOW ENGINE INNODB STATUS\G 中找 HISTORY LIST LENGTH，持续 > 10000 就得干预，> 50000 属高危
• 确认引擎类型：SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' AND ENGINE != 'InnoDB'；只要存在 MyISAM 表，--single-transaction 就会退化为全局读锁

真正安全的高并发备份方案

逻辑备份靠 mysqldump 本身就扛不住高并发写入压力，物理备份才是正解。

• 用 xtrabackup --backup 替代 mysqldump：不依赖 SQL 层事务，不触发 FLUSH TABLES WITH READ LOCK，对写入几乎无感知
• 备份后必须 --prepare 才能恢复：xtrabackup --prepare --target-dir=/backup/full_2024-06-01
• 增量靠 binlog：从 xtrabackup_binlog_info 获取起始位点，再用 mysqlbinlog 截取日志；注意定期 FLUSH BINARY LOGS 控制单文件大小
• 别忽略 undo log 本身：若 innodb_max_undo_log_size 是默认 1GB，建议调小到 134217728（128MB），并确保 innodb_undo_log_truncate=ON

最常被忽略的一点：purge 线程再快，也清不完被长事务钉住的 undo。调参只是加速清理，治本还得靠及时发现和终止异常长事务——监控 INFORMATION_SCHEMA.INNODB_TRX 必须纳入日常巡检。