mysqldump 怎么使用？网站数据库迁移和备份的实用命令

对于运行PHP、WordPress、自建CMS或者其他MySQL网站的服务器来说，数据库备份往往比程序文件备份更加重要。网站代码丢失通常还可以重新部署，但用户账户、文章、订单、评论和配置数据一旦丢失，恢复成本可能非常高。MySQL提供的mysqldump虽然是一个传统的命令行工具，但对于中小型网站、服务器迁移以及定期全量备份来说依然非常实用。真正需要掌握的并不是几个简单参数，而是如何保证备份的一致性、如何安全保存密码，以及最重要的事情：备份完成以后能不能真正恢复。

最基本的操作是导出整个数据库。典型命令如下：

mysqldump -u root -p mydb > mydb_backup.sql

执行后系统会要求输入MySQL密码。这里的-p后面不要直接写密码，这样可以避免密码出现在Shell历史记录或者进程参数中。输入密码以后，mysqldump会把数据库结构和数据写入SQL文件。

如果只需要备份某一张表，可以指定表名：

mysqldump -u root -p mydb news > news_backup.sql

也可以一次导出多张表：

mysqldump -u root -p mydb news users comments > partial_backup.sql

这种方式适合临时导出指定数据，但它不能被称为真正意义上的“增量备份”。mysqldump本身主要用于逻辑备份，并没有因为一次只导出几张表就自动建立增量备份体系。真正的增量恢复通常需要利用MySQL二进制日志（binary log）等机制，或者使用专门的备份工具。

对于网站生产数据库，最常用的参数之一是--single-transaction：

mysqldump -u root -p --single-transaction mydb > mydb_backup.sql

这个参数特别适合主要使用InnoDB存储引擎的数据库。mysqldump会在事务一致性快照的基础上读取数据，因此通常可以在网站继续提供服务的情况下进行备份，而不需要长时间锁住InnoDB表。

这里需要纠正一个非常常见的误解：--single-transaction并不是“确保备份期间数据库不能被修改”。恰恰相反，它的价值就在于让备份能够在数据库继续接受写入的情况下获得一致性视图。备份过程中其他事务仍然可以提交修改，只是这些修改不会随意破坏本次快照的一致性。

因此，生产环境中的一个常见组合是：

mysqldump -u root -p \
--single-transaction \
--quick \
--routines \
--triggers \
--events \
mydb > mydb_backup.sql

其中--quick让mysqldump以流式方式读取大表，而不是试图把大量数据一次性缓存到客户端内存中。对于网站数据库，--routines、--triggers和--events也值得根据实际情况考虑，否则只恢复表结构和数据，却漏掉存储过程、触发器或事件，恢复后的数据库可能无法完全恢复原来的业务逻辑。

如果网站数据库比较大，可以直接进行压缩：

mysqldump -u root -p \
--single-transaction \
--quick \
mydb | gzip > mydb_$(date +%Y%m%d).sql.gz

恢复压缩备份时不一定需要先解压到磁盘，可以直接：

gzip -dc mydb_20260926.sql.gz | mysql -u root -p mydb

这样可以减少临时SQL文件占用的磁盘空间。对于磁盘空间有限的Web服务器，这一点尤其有用。

数据库迁移也是mysqldump非常常见的用途。例如从旧服务器迁移到新服务器，可以先导出：

mysqldump -u root -p \
--single-transaction \
--quick \
--routines \
--triggers \
--events \
mydb > mydb.sql

把SQL文件传到新服务器后，先创建目标数据库，再执行：

mysql -u root -p mydb < mydb.sql

如果备份文件本身包含CREATE DATABASE和USE语句，也可以采用相应的数据库导出方式，让恢复过程自动创建数据库。实际迁移前应该打开SQL文件检查头部内容，而不是假设所有mysqldump文件都包含建库语句。

字符集也是迁移时经常被忽略的问题。现代网站通常应该优先使用utf8mb4，因为它能够覆盖完整Unicode字符范围。迁移以后如果出现中文乱码、emoji丢失或者排序行为异常，需要检查数据库、表、连接以及客户端的字符集配置，而不是简单重新导入一次。

跨MySQL版本迁移时，也不要把--compatible=ansi当成万能兼容参数。MySQL不同版本之间的语法、默认行为、认证插件、字符集和数据类型可能存在差异。真正可靠的迁移方式是确认源服务器和目标服务器的MySQL版本，检查SQL文件中是否包含目标版本不支持的语法和特性，并在正式切换之前完成一次完整的测试恢复。

如果数据库使用的是MySQL 8.x，迁移时还应该特别注意账户认证方式以及用户账户本身的迁移。mysqldump mydb导出的是指定数据库中的对象和数据，并不等于自动把MySQL服务器上的所有用户、权限和认证配置一起迁移过去。因此新服务器上的数据库用户和权限通常需要单独检查和配置。

对于大型网站，mysqldump的性能也需要认真考虑。--quick通常是基本选择，但它并不能让大型数据库备份变成毫无成本的操作。备份期间仍然会消耗磁盘I/O、CPU以及网络带宽。如果数据库规模已经达到数十GB、数百GB甚至更大，应该根据业务停机要求和恢复时间目标考虑物理备份、MySQL Enterprise Backup、Percona XtraBackup等更适合大型数据库的方案，而不是无限制地依赖mysqldump。

所谓“分页导出”也不能简单理解成把mysqldump加上LIMIT。mysqldump不是这样工作的。像下面这种SQL：

SELECT * FROM news LIMIT 1000,2000;

只是查询部分数据，并不能自动产生一个完整、可验证、可恢复的mysqldump备份。对于超大型单表，如果确实需要按照主键范围分批处理，应根据业务数据结构设计明确的导出方案，并处理主键连续性、并发写入以及跨表关联等问题。对于普通网站，没有必要为了所谓“分页备份”把简单的mysqldump流程复杂化。

备份权限也不能简单写成“必须有RELOAD权限”。mysqldump实际需要的权限取决于导出的对象和使用的参数。例如锁表、触发器、事件、存储过程以及特定服务器级信息都会涉及不同权限。生产环境更合理的做法是创建专门的备份账户，只授予备份任务实际需要的权限，而不是长期使用root账户执行所有自动化任务。

密码管理同样非常重要。定时任务不应该把数据库密码直接写成：

mysqldump -u root -p'password' mydb > backup.sql

这种写法很容易把敏感信息暴露在脚本、备份文件或者权限不当的服务器环境中。可以使用MySQL客户端配置文件，例如~/.my.cnf，并严格限制文件权限：

[client]
user=backupuser
password=your_password

然后：

chmod 600 ~/.my.cnf

之后备份命令可以直接使用：

mysqldump mydb > backup.sql

生产环境中还应该考虑备份文件本身的安全性。SQL文件可能包含用户资料、邮箱、订单信息以及其他敏感数据，因此不能因为它只是一个“.sql文件”就把它放在网站公开目录。例如不要把数据库备份直接放在public_html、www或者其他Web服务器可以直接访问的目录中。更合理的方式是放到Web根目录之外，并限制操作系统权限。

备份完成以后，还应该检查文件大小和生成状态。例如：

ls -lh mydb_backup.sql

对于压缩文件：

ls -lh mydb_backup.sql.gz

必要时可以检查SQL文件是否能够正常读取：

head -n 30 mydb_backup.sql

但文件存在并不代表备份可靠。真正重要的是进行恢复测试。

可以在测试数据库中建立一个独立数据库：

mysql -u root -p -e "CREATE DATABASE mydb_test CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;"

然后恢复：

mysql -u root -p mydb_test < mydb_backup.sql

恢复完成后检查表数量、关键表记录数量、触发器、存储过程以及网站实际查询结果。对于重要网站，定期恢复测试比单纯每天生成一个SQL文件更加重要。因为“备份成功”只证明导出命令执行完了，而“恢复成功”才证明这份备份真正具有灾难恢复价值。

如果需要自动执行，可以使用cron。例如每天凌晨2点执行：

0 2 * * * /usr/bin/mysqldump --single-transaction --quick mydb | gzip > /backup/mydb_$(date +\%Y\%m\%d).sql.gz

但是自动备份还需要解决文件数量不断增加的问题。可以配合find删除超过一定保存期限的旧备份，例如保留30天：

find /backup -name 'mydb_*.sql.gz' -type f -mtime +30 -delete

实际生产环境中还应该把备份复制到另一台服务器、对象存储或者其他独立存储介质。把数据库备份和网站服务器放在同一块硬盘上，并不能真正解决硬盘损坏、服务器故障、勒索软件或者误删除问题。

对于需要更严格恢复能力的网站，还应该区分全量备份和二进制日志。mysqldump可以定期生成完整数据库快照，而MySQL binary log可以记录数据库发生的变更。通过全量备份加二进制日志，可以建立比单纯每天一次mysqldump更加完整的恢复体系，例如先恢复最近一次全量备份，再根据保存的二进制日志恢复到更接近故障发生前的时间点。

这也是需要纠正原稿中“使用--master-data创建基于GTID的增量备份”的地方。--master-data主要用于在备份中记录二进制日志坐标等复制相关信息，并不等于mysqldump自动产生了一个完整的GTID增量备份系统。GTID、binary log、复制和逻辑备份属于不同层面的机制，需要根据MySQL版本和复制架构分别设计。

如果只是一个中小型博客、资讯网站或者普通PHP网站，定期mysqldump加gzip已经可以构成相当实用的基础备份方案。对于交易量较大的电商网站、高并发业务或者数据规模很大的生产数据库，则应该进一步考虑备份窗口、I/O压力、RPO（Recovery Point Objective）、RTO（Recovery Time Objective）、二进制日志以及物理备份工具。

最终判断数据库备份是否合格，不是看cron有没有每天执行，也不是看backup.sql.gz文件有没有出现在目录里，而是看服务器发生故障以后，能否在另一台机器上把数据库完整恢复出来，并让网站重新正常工作。对网站运维来说，真正有价值的备份永远不是“保存了一份文件”，而是建立了一条经过验证的恢复路径。