优先选 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 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 版本必须严格匹配 MySQL：MySQL 8.0.33 → 必须用
xtrabackup-808.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 页面，备份时没报错，恢复时才暴露。所以校验要三层覆盖：
- 文件完整性：
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（时间点恢复）能力，备份就只是“半成品”。
