备份期间执行大批量UPDATE极大概率导致备份失败或卡住，因mysqldump默认加全局读锁（FLUSH TABLES WITH READ LOCK），与UPDATE形成互相等待；即使分批UPDATE也会加剧redo log、脏页和buffer pool争抢，物理备份同样面临IO与校验风险；安全做法是错开备份与批量更新窗口。
备份期间执行大批量 UPDATE 极大概率导致备份失败或卡住，这不是配置问题，而是 MySQL 5.7 的锁机制与备份逻辑冲突所致。
mysqldump 逻辑备份会触发全局读锁（FLUSH TABLES WITH READ LOCK）
默认情况下，mysqldump 在开始导出前会执行 FLUSH TABLES WITH READ LOCK，这个操作会让所有写入（包括 UPDATE、INSERT、DELETE）被阻塞，直到锁释放。如果你在备份中途发起大批量 UPDATE：
- 该
UPDATE会一直等待读锁释放，而读锁又依赖于mysqldump完成所有表的 dump —— 形成互相等待 - 若
UPDATE涉及大范围扫描（如没走索引），还会拖慢mysqldump获取元数据的速度 - 超时后可能触发连接中断，
mysqldump报错退出，备份文件不完整
物理备份（如 XtraBackup）虽不加全局读锁，但仍有写入干扰风险
Percona XtraBackup 等工具采用复制 redo log + 拷贝 ibdata 的方式，理论上允许备份期间写入。但在 MySQL 5.7 中：
- 大批量
UPDATE会急剧放大 redo log 写入压力，可能导致log buffer频繁刷盘，IO 尖峰拖慢备份进度 - 如果
UPDATE触发大量页分裂或 B+ 树重构，备份过程中页状态不稳定，XtraBackup 可能校验失败 - 备份窗口内事务 ID（
trx_id）持续增长，恢复时若ibbackup_binlog_info记录偏移不准，主从同步易断
为什么分批 UPDATE 也不建议和备份同时跑？
即使你用 LIMIT 分批次执行 UPDATE，仍存在隐性冲突：
- 每次
UPDATE ... LIMIT N仍是独立事务，会生成新的 undo log 和 redo log 条目，加剧日志系统负载 - MySQL 5.7 的
innodb_log_file_size默认较小（如 48MB），大批量更新容易触发频繁 checkpoint，与备份争抢 buffer pool - 备份工具监控
Innodb_buffer_pool_pages_dirty值，若脏页比例持续高于阈值（如 75%），可能主动暂停备份等待刷脏
真正安全的做法是：把备份窗口和批量更新错开，尤其避免在 mysqldump 运行期间提交任何写事务；若必须并行，只允许轻量级、单行、索引命中的 UPDATE，且确保 innodb_flush_log_at_trx_commit=2 降低 redo 刷盘频率。
