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 效率不升反降。
面向 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 必须纳入日常巡检。


















