--single-transaction会等待长事务结束，因其依赖START TRANSACTION WITH CONSISTENT SNAPSHOT，而InnoDB需等所有更早事务提交或回滚才能建立快照，否则备份卡住、purge阻塞、undo log堆积、主从延迟加剧。
会卡住备份、拖垮主库、甚至导致备份文件不可用——不是“可能”，而是只要长事务没结束，--single-transaction 就动不了。
为什么 mysqldump --single-transaction 会等长事务结束
这个参数本质是执行 START TRANSACTION WITH CONSISTENT SNAPSHOT，而 InnoDB 要建立一致快照，必须等所有更早启动的事务都提交或回滚。如果有个事务已运行 10 分钟还没 COMMIT，mysqldump 就会在那干等，直到超时（默认 wait_timeout 或 interactive_timeout 触发）。
- 现象：备份进程卡在
Waiting for table flush或Starting transaction状态，SHOW PROCESSLIST里能看到状态为Waiting for global read lock（其实是被 MVCC 快照机制阻塞） - 后果不止是备份慢：它会拖住 purge 线程，导致 undo log 不释放，
innodb_history_list_length持续飙升，磁盘空间和内存压力同步上涨 - 更隐蔽的问题：长事务期间产生的大量版本链，会让备份后
mysqldump读取数据时反复回溯旧版本，IO 和 CPU 使用率异常升高
大事务 + 备份 = 主从延迟爆炸
大事务本身就会让 binlog 写入延迟、复制线程堆积；一旦叠加备份，问题会放大：
-
mysqldump --single-transaction虽不锁表，但会拉长事务视图生命周期，间接延长从库重放时间 - 若备份过程中主库还有新事务提交，从库要等主库上所有前置事务（含那个大事务）全部写完 binlog 才能追上，
Seconds_Behind_Master可能从几秒跳到几百秒 - 极端情况下，从库 IO 线程卡在
Reading event from the relay log，SQL 线程卡在Waiting for dependent transaction to commit，恢复缓慢
xtrabackup 也逃不开长事务的影响
物理备份看似“绕过 SQL 层”，但依然受底层事务状态牵制：
- 备份开始前的
FLUSH TABLES WITH READ LOCK（FTWRL）虽只持续毫秒级，但如果此时恰好有长事务未结束，FTWRL 会被阻塞——xtrabackup 默认会等，直到超时失败 - 即使 FTWRL 成功，
--prepare阶段回放 redo log 时，若遇到长事务未提交的脏页，需要依赖其对应的 undo log 来 rollback，而 undo log 若因 purge 延迟被截断（innodb_max_purge_lag触发），prepare 就会报错InnoDB: Error: page ... corrupt - 备份目录里生成的
xtrabackup_binlog_info和xtrabackup_checkpoints若记录了不稳定的 LSN，后续恢复或搭建从库时可能定位到错误位点
真正安全的备份窗口必须避开大事务
别指望“加个参数就能扛住”——关键不在工具，而在事务行为本身：
- 上线前必须查：
SELECT trx_id, trx_started, trx_state, trx_isolation_level FROM information_schema.innodb_trx WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 30;，把 >30 秒的事务全干掉或拆分 - 业务侧要限制单次事务操作行数，比如电商下单不能一次扣 10 万 SKU 库存，得走批量分片+异步补偿
- 备份脚本里加前置检查：用
SELECT COUNT(*) FROM information_schema.innodb_trx WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 10;判断，结果 >0 就中止备份并告警 - MyISAM 表混用时，大事务+备份=双重灾难：既无法用
--single-transaction，又不能靠 xtrabackup 完全规避锁，只能选--lock-all-tables并接受短暂写入中断
最常被忽略的一点：监控 innodb_row_lock_time_avg 和 innodb_history_list_length 这两个指标比看慢查询日志更能提前暴露隐患——它们一涨，备份就危险。
