一、适用场景：什么时候需要用 mysqldump 备份和恢复
mysqldump 是 MySQL 官方自带的逻辑备份工具，不需要额外安装任何软件，只要服务器上能运行 mysql 命令，就一定有 mysqldump。对于个人站长、中小企业的运维人员来说，它是最简单、最通用、也最值得掌握的数据库备份方式。
常见的使用场景包括：网站迁移服务器前需要把数据库完整导出；升级 MySQL 版本前做一次安全快照；误删数据或误操作后需要恢复到某个时间点；定期做自动化备份以保证业务数据安全。无论是 WordPress、Discuz 还是自研系统，只要后端是 MySQL，本文的步骤都适用。
与宝塔面板自带的"备份数据库"按钮相比，mysqldump 的优势在于可控性强：可以只导出某一张表、可以压缩体积、可以配合 crontab 做无人值守的定时备份。掌握命令行操作，即使面板出问题也能手工完成备份，这是站长的一项基本保险。
二、准备工作：确认连接信息并创建备份目录
在开始之前，需要确认以下信息：数据库名、数据库用户名和密码，以及 MySQL 服务器的地址（本机一般为 localhost 或 127.0.0.1）。如果是宝塔面板，可以在"数据库"页面直接看到这些信息；如果是手工安装的 MySQL，可以查看站点配置文件（例如 WordPress 的 wp-config.php）中的数据库配置段。
同时建议先创建一个专门的备份目录，避免备份文件散落在系统各处。执行以下命令创建目录：
mkdir -p /www/backup/mysql && cd /www/backup/mysql
注意：备份文件包含完整的业务数据，请确保该目录权限收紧，不要放在网站根目录等可被公开访问的位置，否则可能造成数据泄露。恢复操作属于高风险动作，正式恢复前务必先确认当前库是否需要先行备份，避免覆盖后无法回退。
第三步：使用 mysqldump 导出（备份）数据库
完整的备份命令如下，请在服务器终端执行：
mysqldump -u root -p --single-transaction --set-gtid-purged=OFF mydatabase > /www/backup/mysql/mydatabase_$(date +%F).sql
回车后系统会提示输入密码，输入数据库密码即可（输入时屏幕不显示，属正常现象）。命令中的各参数含义：-u 指定用户名，-p 表示交互式输入密码（不建议直接把密码写在命令里，会被 shell 历史记录）；--single-transaction 保证在 InnoDB 引擎上备份期间不锁表，业务可以继续读写；$(date +%F) 会自动生成形如 2026-10-15 的日期后缀，方便区分不同日期的备份文件。
如果只需要备份某一张表，可以在库名后面追加表名，例如 mysqldump -u root -p mydatabase wp_posts > wp_posts.sql。执行完成后，用 ls -lh 查看备份文件大小，正常情况下应与数据库实际数据量接近；如果文件只有几百字节，说明备份过程可能出错，需要检查用户名、密码和库名是否正确。
如果要备份服务器上的所有数据库，可以使用 mysqldump -u root -p --all-databases > all_$(date +%F).sql，这种方式常用于整机迁移前的全量快照。
第四步：压缩备份文件以节省磁盘空间
文本格式的 SQL 文件压缩率很高，通常能缩小到原文件的十分之一左右。可以在导出的同时通过管道直接压缩：
mysqldump -u root -p --single-transaction mydatabase | gzip > /www/backup/mysql/mydatabase_$(date +%F).sql.gz
恢复时不需要手动解压，直接使用 gunzip 或 zcat 配合管道即可（见下一节）。对于磁盘空间紧张的服务器，这一步几乎是必做的：一个 2GB 的数据库压缩后通常只有 200MB 左右。
另外建议为备份文件设置合理的保留策略，例如只保留最近 30 天的备份，定期清理更早的文件，避免备份目录本身把磁盘占满。清理属于删除类操作，执行前务必逐个确认文件名，不要使用通配符批量误删。
第五步：使用 mysql 命令导入（恢复）数据库
恢复是指把备份的 SQL 文件重新写入数据库。如果目标数据库还不存在，需要先创建它：
mysql -u root -p -e "CREATE DATABASE mydatabase DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
然后导入备份文件。普通 SQL 文件使用以下命令：
mysql -u root -p mydatabase < /www/backup/mysql/mydatabase_2026-10-15.sql
如果是压缩过的 .gz 文件，使用 zcat 管道导入：
zcat /www/backup/mysql/mydatabase_2026-10-15.sql.gz | mysql -u root -p mydatabase
导入大文件可能需要几分钟到几十分钟，期间不要中断终端连接。建议在 screen 或 tmux 会话中执行，或者使用 nohup 挂后台，避免 SSH 断开导致导入中断。导入完成后，登录数据库用 SHOW TABLES; 和抽查几条核心数据来确认恢复结果。
特别提醒：导入会覆盖目标库中的同名数据。如果目标库正在被线上业务使用，请先评估业务影响并提前公告停机或维护窗口，恢复前对当前库再做一次备份，给自己留一条回退路径。
第六步：用 crontab 实现每天自动备份
手工备份容易忘，推荐配置定时任务自动执行。先创建一个备份脚本 /www/backup/mysql/backup.sh，内容如下：
#!/bin/bash
mysqldump -u root -p"你的密码" --single-transaction mydatabase | gzip > /www/backup/mysql/mydatabase_$(date +%F).sql.gz
find /www/backup/mysql -name "*.sql.gz" -mtime +30 -delete
然后执行 chmod +x /www/backup/mysql/backup.sh 赋予执行权限，再用 crontab -e 添加一行：
0 3 * * * /www/backup/mysql/backup.sh
表示每天凌晨 3 点自动备份并清理 30 天前的旧备份。注意：脚本中明文写入密码有一定安全风险，建议为备份单独创建一个只读权限的数据库账号，并在备份完成后把文件同步到异地（如对象存储或另一台服务器），避免服务器故障时备份和数据库一起丢失。修改 crontab 前建议先用 crontab -l 备份现有任务列表。
常见问题 FAQ
1. 执行 mysqldump 时提示 command not found 怎么办？说明 mysqldump 不在 PATH 环境变量中，常见于手工编译安装的 MySQL。可以用 find / -name mysqldump 找到实际路径，或者把 MySQL 的 bin 目录加入 PATH。宝塔环境下路径通常是 /www/server/mysql/bin/mysqldump，可以直接用完整路径执行。
2. 导入时报错 Unknown collation 或字符集错误？多数是高版本 MySQL 导出的文件导入到低版本导致的。可以在导出时加 --compatible 或确认两端版本；WordPress 站点常见于 utf8mb4_unicode_520_ci 排序规则，可在导入前将 SQL 文件中的该排序规则替换为 utf8mb4_unicode_ci。替换前同样先备份原文件。
3. 备份文件很大，导入速度很慢怎么办？大文件导入慢是正常现象，可以通过以下方式提速：导入前在目标库执行 SET foreign_key_checks=0;；确保导入文件没有开启逐行提交；硬件层面使用 SSD。切忌为了提速直接关闭 MySQL 服务或强杀进程，可能损坏数据。
4. 如何验证备份文件是有效的？最可靠的方法是在测试环境中做一次完整恢复演练：新建一个测试库，把备份文件导入进去，检查表数量和核心数据。只看文件大小或用 head 抽看文件头是不够的，定期演练恢复才能真正保证备份可用。
总结
mysqldump 是 MySQL 官方自带的备份恢复工具，覆盖了从单表导出、整库备份、压缩存储到定时自动备份的完整链路。核心命令只有两条：导出用 mysqldump，恢复用 mysql 命令加输入重定向。实际使用中要记住三个原则：备份文件不放在可公开访问的目录；恢复属于覆盖性操作，动手前先备份当前库、评估业务影响；备份要做异地保存并定期演练恢复，这样数据安全才真正落地。
暂无评论内容