mysqldump加锁导致select变慢，根本原因是默认启用--lock-tables（myisam）或innodb下--single-transaction遇长事务时mvcc版本链过长，引发表级锁等待或查询响应延迟；应使用--single-transaction --skip-lock-tables、避开高峰、检查并清理长事务、优先在只读从库执行，并配合限速、压缩、分库导出及错开其他后台任务。
mysqldump加锁导致SELECT变慢怎么办
直接原因往往是 mysqldump 默认启用 --lock-tables（MyISAM）或在 InnoDB 下隐式使用 --single-transaction 但配合长事务时仍会拖慢查询。业务 SELECT 等待表级锁或 MVCC 版本链过长，响应明显延迟。
- 确认是否真被锁：执行
SHOW PROCESSLIST，看是否有大量Waiting for table metadata lock或状态为Sending data却长时间卡住 - 对 InnoDB 表，强制禁用锁表、启用快照一致性：
mysqldump --single-transaction --skip-lock-tables - 避开业务高峰，同时检查备份前是否存在未提交的长事务：
SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5；若有，需协调应用侧尽快提交或回滚 - 避免在主库直接备份；优先切到从库执行，且确保从库
read_only=ON不被误写
备份时CPU/IO打满影响线上QPS
mysqldump 是单线程全表扫描，尤其大表导出时持续读盘+序列化拼SQL，极易吃光磁盘带宽和CPU资源，连带拖慢 innodb_buffer_pool 命中率，让正常查询也频繁刷盘。
- 限速是最快见效手段：用
--rate-limit=1024（单位 KB/s）或更细粒度的--compress+pv -L 2m控制管道吞吐 - 跳过非核心表：用
--ignore-table=db1.audit_log --ignore-table=db1.tmp_*过滤日志、临时、历史归档表 - 考虑替代方案：Percona XtraBackup 支持热备+并行压缩，对 IO 压力更友好；但注意它要求
innodb_file_per_table=ON且不兼容某些云厂商托管 MySQL 的权限模型
备份文件过大导致网络/存储瓶颈
未压缩的 SQL 文本体积常达原始数据的 3–5 倍，传输或写入慢盘时会延长锁持有时间或触发系统级 IO 调度拥塞，间接加剧业务抖动。
- 必须启用压缩：
mysqldump ... | gzip > backup.sql.gz，别用--compress（那是客户端/服务端协议压缩，不减文件体积） - 分库分表导出：用
mysql -e "SHOW DATABASES LIKE 'app%'"动态生成脚本，按库并行 dump（注意控制并发数 ≤ 3，避免争抢连接数） - 避免在数据库服务器本地落盘再 rsync —— 直接管道推送到远端：
mysqldump ... | gzip | ssh backup@10.0.1.100 "cat > /bkp/app_$(date +%F).sql.gz"
binlog 日志暴涨拖慢主从同步
如果备份期间发生大批量 DML（比如定时任务跑批），而 mysqldump 又没关掉 --flush-logs，会导致 binlog 文件陡增，从库重放压力加大，甚至出现复制延迟飙升。
- 默认不要加
--flush-logs；如需记录备份点位，改用--master-data=2（自动注入 CHANGE MASTER 命令）即可 - 检查
expire_logs_days是否设置合理（建议 ≥ 7），避免旧 binlog 挤占磁盘空间引发disk full报错 - 若已出现延迟，先确认从库是否因
slave_parallel_workers > 0但表结构无主键导致并行退化为串行 —— 查SHOW SLAVE STATUS\G中Seconds_Behind_Master和Slave_SQL_Running_State
实际优化效果取决于你的实例规格、数据量级和业务波峰特征。最易被忽略的是：备份窗口内其他后台任务（如 pt-online-schema-change、analyze table、慢查询日志轮转）是否也在争抢资源——建议把它们全部错开或临时禁用。
