优先选 Percona XtraBackup；若必须用 mysqldump，仅 --single-transaction --quick --net_buffer_length=1M --max_allowed_packet=512M 可勉强运行，但风险高、耗时长、恢复慢。

直接结论：别用 mysqldump，优先选 Percona XtraBackup；若必须用逻辑备份，mysqldump --single-transaction --quick --net_buffer_length=1M --max_allowed_packet=512M 是唯一能勉强跑通的组合，但风险高、耗时长、恢复慢。

为什么 mysqldump 对百GB大表基本不可行

不是语法写错，是底层机制决定它扛不住：默认逐表读取+内存拼接 SQL，遇到百GB单表，mysqldump 会不断申请 buffer，最终触发 Lost connection to MySQL server during query 或被 innodb_lock_wait_timeout 中断。即使加了 --single-transaction，只要备份事务持续时间超过 60 秒（常见于大表扫描），InnoDB 就可能清理快照，导致一致性失败。

• 混合引擎表（如含 MyISAM）会让 --single-transaction 失效，自动退化为 --lock-tables，锁死写入
• --where 分批导出看似可行，但跨批次之间无事务隔离，中间写入的数据会丢失或重复
• 导出文件动辄 30–50 GB，网络传输、磁盘 IO、解压导入全是瓶颈，RTO 很难控制在分钟级

Percona XtraBackup 是唯一真正可用的热备方案

XtraBackup 直接复制 InnoDB 的物理页，不走 SQL 解析层，因此天然规避锁表和内存溢出问题。但它不是“开箱即用”，几个关键点必须卡准：

• 版本必须严格匹配 MySQL：MySQL 8.0.33 → 必须用 xtrabackup-80 8.0.33，混用会报 InnoDB: Page directory corruption
• 备份用户至少需要 BACKUP_ADMIN, RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT 权限；LOCK TABLES 是为了执行 FLUSH TABLES WITH READ LOCK 获取 binlog 位点，仅毫秒级阻塞
• IO 压力真实存在：全量备份期间磁盘吞吐飙升，建议用 --throttle=100 限速，避免拖垮线上业务
• 必须执行 xtrabackup --prepare 才能恢复：跳过这步直接拷贝文件启动 MySQL，必然崩溃

备份后校验不能省，且必须分层做

物理备份看似“快”，但损坏静默发生率比逻辑备份更高——比如磁盘坏道只影响某个 ibd 页面，备份时没报错，恢复时才暴露。所以校验要三层覆盖：

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

• 文件完整性：md5sum backup_dir/xtrabackup_checkpoints 和 backup_dir/backup-my.cnf 确保元数据未被截断
• 结构一致性：用 xtrabackup --verify-backup（XtraBackup 8.0.30+ 支持），比手动 innodb_force_recovery 启动更快更安全
• 数据抽样验证：从备份中快速启一个临时实例，执行 SELECT COUNT(*) FROM big_table LIMIT 1 和 CHECKSUM TABLE big_table，对比源库结果

真正容易被忽略的点：binlog 必须同步归档

再快的全量备份也只是某个时间点的快照。百GB大表恢复后，你不可能靠重放全部 binlog 回到最新状态——那可能要数小时。所以每次 XtraBackup 完成，必须立刻执行：

mysql -e "SHOW MASTER STATUS\G" | grep -E "(File|Position)"

并把对应 mysql-bin.000xxx 文件拷到独立存储（如 S3 或 NAS）。没有这个 binlog 位点，你就失去了 PITR（时间点恢复）能力，备份就只是“半成品”。