mysqldump 备份大库卡住或超时需调优参数：加--single-transaction、--net_buffer_length=1M、--max_allowed_packet=512M，禁用自动提交与外键检查，并分表导出；TB级推荐Percona XtraBackup物理热备，配合限速与权限校验；压缩用gzip-3或zstd，传输前本地落盘；备份后须校验文件大小、头尾SQL结构及表数据一致性。
mysqldump 备份大库时卡住或超时怎么办
直接用 mysqldump 导出几百 GB 的库，大概率会失败：连接超时、内存溢出、锁表太久导致业务阻塞。根本原因不是命令写错了，而是默认参数完全没考虑大数据量场景。
- 加
--single-transaction（InnoDB 必须），避免全表锁，但前提是事务不能太长——否则可能被innodb_lock_wait_timeout中断 - 必须设
--net_buffer_length=1M和--max_allowed_packet=512M，否则网络缓冲区撑爆，报错Lost connection to MySQL server during query - 禁用自动提交和外键检查：
--skip-autocommit --no-tablespaces --skip-triggers --skip-routines，减少 dump 过程中的额外开销 - 不要一次性导整个库，用
--databases拆成单表或小批量表导出，比如每次 5–10 张活跃度低的表
如何不锁表、不拖慢线上业务做备份
核心思路是绕过 MySQL 主流程，从存储层拿数据。适合 TB 级、无法停写、SLA 要求高的场景。
-
Percona XtraBackup是唯一靠谱选择：物理备份、支持增量、真正热备。注意版本要匹配 MySQL（例如 MySQL 8.0.33 用 XtraBackup 8.0.33） - 执行前确认
datadir权限正确，备份用户需有RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT权限 - 避免在高峰期间跑
xtrabackup --backup，它仍会读取大量页，IO 压力明显；可配合--throttle=100（每秒 IO 操作数）限速 - 别跳过
--prepare阶段直接恢复，否则会报InnoDB: Page directory corruption
备份文件太大，传输和压缩怎么不崩
导出的 SQL 文件动辄上百 GB，gzip 压缩本身吃内存，管道处理不当会卡死或丢数据。
- 用
pv监控流速：mysqldump ... | pv -s 20G | gzip > backup.sql.gz，避免盲等 - 别用
gzip -9——压缩率只高 2%，但耗时翻倍、内存占用暴涨；gzip -3或zstd -T1 --fast=1更实用 - 如果磁盘空间不足，改用
mbuffer缓冲：mysqldump ... | mbuffer -m 2G | gzip > backup.sql.gz，防止生产端因下游慢而阻塞 - 切忌边 dump 边 rsync 到远端——网络抖动会导致管道中断，建议先落本地，再异步传
备份后怎么快速验证不是空文件或半截包
备份完成不等于可用。曾见过定时任务里 mysqldump 因权限问题静默失败，生成了 1KB 的空 SQL 文件，半年都没人发现。
- 检查文件大小下限：
[ $(stat -c%s "backup.sql.gz") -gt 1000000 ]，小于 1MB 基本可疑 - 抽样看头尾：
zcat backup.sql.gz | head -20应含CREATE DATABASE或USE；zcat backup.sql.gz | tail -10应含UNLOCK TABLES或COMMIT - 用
mysqlcheck --check --databases your_db对源库做一致性快照比对（需提前记录SELECT COUNT(*) FROM table结果） - 最硬核但有效：挑一张小表，在测试环境
mysql -e "DROP TABLE t; CREATE TABLE t LIKE prod.t;"后导入该表片段，看是否报错
