不会直接阻塞SQL线程，但可能间接拖慢复制：加--single-transaction时不锁表、不影响SQL线程；未加且锁表则触发FLUSH TABLES WITH READ LOCK阻塞SQL线程；大表dump还会加剧I/O和网络压力导致延迟上升。
从库执行 mysqldump 会不会阻塞复制？
不会直接阻塞 SQL 线程，但可能间接拖慢复制进度。关键看是否加 --single-transaction 和是否锁表。
- 加
--single-transaction（InnoDB 默认行为）：只在 dump 开始时加一个全局读视图，不锁表，SQL 线程照常回放 relay log - 没加且用了
--lock-all-tables或遇到 MyISAM 表：会触发FLUSH TABLES WITH READ LOCK，阻塞 SQL 线程直到 dump 结束 - 即使不锁表，大表 dump 也会显著增加磁盘 I/O 和网络压力，导致 SQL 线程延迟上升（
Seconds_Behind_Master增大）
备份时如何避免影响主库和从库业务？
核心原则：所有操作只在从库本地进行，主库完全无感知；从库自身需短暂暂停写入或错峰操作。
- 确认从库已停止写入（应用层隔离或
SET GLOBAL read_only = ON），防止备份期间有 DML 写入导致 binlog 位点混乱 - 用
--skip-lock-tables+--single-transaction组合，避免锁表引发的连接堆积 - 限制资源：通过
--compress减小网络传输量；用ionice -c2 -n7（Linux）降低 I/O 优先级；必要时加--quick防止内存溢出 - 避开业务高峰，尤其注意
mysqldump对 buffer pool 的冲击——它会把大量热数据页刷进磁盘，导致后续查询变慢
mysqldump 备份后怎么还原成新从库？
不能直接还原到运行中的从库，必须还原到全新实例，并重置复制起点。
- 还原前先停掉目标 MySQL 实例，清空数据目录（或用
mysql --execute="DROP DATABASE ..."清库） - 用
mysql 导入；导入完成后检查 <code>SHOW MASTER STATUS，确认File和Position是空值（说明没启用 binlog） - 关键一步：从原备份文件里提取
CHANGE MASTER TO所需参数——mysqldump默认会在注释里写上-- CHANGE MASTER TO MASTER_LOG_FILE='xxx', MASTER_LOG_POS=yyy; - 启动新实例，执行
CHANGE MASTER TO+START SLAVE，再查SHOW SLAVE STATUS\G确认Slave_IO_Running和Slave_SQL_Running都为Yes
为什么不能用 rsync 直接拷贝从库数据目录做热备？
因为 InnoDB 文件不是静态快照，直接拷贝大概率损坏，且无法保证 binlog 与数据文件的一致性。
- InnoDB 的
ibdata1、ib_logfile*在运行中持续写入，rsync无法保证原子性，恢复后大概率报innodb: Database page corruption - 即使加上
FLUSH TABLES WITH READ LOCK，也无法冻结 redo log 和 undo log 的内部状态，MySQL 启动时仍需 crash recovery，结果不可控 -
mysqldump是逻辑备份，能跨版本、跨平台；而物理拷贝要求源目 MySQL 版本、配置（尤其是innodb_page_size）、甚至操作系统架构严格一致 - 真正安全的物理热备方案是
Percona XtraBackup，它通过 hook 进入 InnoDB 内部，边拷贝边处理日志，但那是另一套机制了
最易被忽略的是：备份时刻的 Exec_Master_Log_Pos 必须和 dump 文件里的 MASTER_LOG_POS 严格对应——很多人只抄了文件名，漏看了位置点，导致新从库一启动就报 Could not find first log file name in binary log index file。
