mysqldump是最常用稳妥的全量备份方式，生成可读SQL文件、无需停机，但InnoDB需加--single-transaction保证一致性快照，MyISAM则触发全局读锁；恢复必须用mysql命令行导入，不可用source，且须定期验证备份有效性。
mysqldump 是最常用、最稳妥的完整备份方式，适用于绝大多数中小规模 MySQL 部署。它生成可读 SQL 文件，不依赖存储引擎类型，也不要求停机，但要注意 InnoDB 和 MyISAM 表在锁行为上的关键差异。
用 mysqldump 做全库备份时必须加 --single-transaction
这个参数只对 InnoDB 有效，作用是启动一个一致性快照，避免备份过程中被长事务阻塞或产生不一致数据。如果不加，mysqldump 默认会执行 FLUSH TABLES WITH READ LOCK，导致整个实例写入阻塞——哪怕只是备份一个库，也会卡住其他库的写操作。
- 只备份
InnoDB库：必须加--single-transaction，否则业务可能明显卡顿 - 混合引擎（含
MyISAM）：该参数无效，mysqldump会退回到全局读锁，此时应考虑停写窗口或改用物理备份 - 备份前确认
innodb_support_xa=ON（MySQL 5.7+ 默认开启），否则快照可能不一致
mysqldump 恢复时不能直接用 source 命令
很多人把备份文件传到服务器后，在 mysql 客户端里输 source /path/backup.sql，结果报错 Unknown command 或乱码。这是因为 source 只能执行单条语句，而 mysqldump 输出包含多段 USE、CREATE、INSERT 以及可能的注释和分隔符，必须由 mysql 命令行客户端直接解析。
- 正确恢复命令：
mysql -u root -p database_name - 如果备份文件含
CREATE DATABASE和USE（即用了--databases或--all-databases），恢复时不能指定库名，应写成：mysql -u root -p - 若目标库已存在且需清空重建，先手动
DROP DATABASE，再恢复；mysqldump不会自动覆盖或跳过已存在对象
备份文件体积大、传输慢？别硬扛，加管道压缩
一个 2GB 的库导出 SQL 可能达 3–5GB（尤其含大量文本或 JSON 字段），直接写磁盘再压缩既占空间又耗时。更高效的做法是在管道中实时压缩。
- 压缩备份：
mysqldump -u root -p --single-transaction --routines --triggers mydb | gzip > mydb_$(date +%Y%m%d).sql.gz - 解压恢复：
zcat mydb_20260810.sql.gz | mysql -u root -p mydb - 注意：
gzip和zcat在大多数 Linux 发行版默认安装；如用xz，对应命令是xz和xzcat，压缩率更高但 CPU 开销略大
.sql 文件，却从不验证能否成功导入、是否缺失 DEFINER 权限、是否因字符集不一致导致中文乱码。建议每月至少一次用测试实例执行完整恢复流程，并检查表行数、主键最大值、关键业务字段样例数据——否则等到故障那天，才发现备份早已失效。 
