MySQL单个数据库备份方法与操作步骤

时间：2026-08-23 09:48

在 MySQL 数据库备份场景中，mysqldump 一直被认为是最直接、最稳定的单库备份方案，尤其适合容量不超过 50GB 的 InnoDB 数据库。其常用核心命令为mysqldump -u root -p mydb > mydb_backup sql。在这条命令里，-u用于指定用户名（例如roo

在 MySQL 数据库备份场景中，mysqldump 一直被认为是最直接、最稳定的单库备份方案，尤其适合容量不超过 50GB 的 InnoDB 数据库。其常用核心命令为mysqldump -u root -p mydb > mydb_backup.sql。在这条命令里，-u用于指定用户名（例如root），-p表示执行后需要手动输入密码（不建议直接把密码明文写进命令中，例如-p123456），mydb表示需要备份的数据库名称，该数据库必须真实存在，否则会报错“mysqldump: Got error: 1049: Unknown database 'mydb'”。同时，重定向符号“>”必不可少，否则备份结果会直接输出到终端，既不便查看也无法保存为 SQL 文件；目标文件路径还必须具备写入权限，例如/backup/mydb_$(date +%F).sql，这样也能避免备份文件被覆盖。另外，为了减少锁表影响，通常需要加上--single-transaction参数。除此之外，--add-drop-table参数、gzip压缩后缀、文件权限以及恢复验证等关键细节也都不能忽略。

MySQL如何备份单个数据库

mysqldump 是备份单个 MySQL 数据库最常见也最稳妥的方法之一，只要数据库规模不超过 50GB，并且存储引擎为 InnoDB，通常都能较为可靠地完成单库导出与备份。

怎么用 `mysqldump` 备份单个数据库

核心备份命令很简单：mysqldump -u root -p mydb > mydb_backup.sql。执行该命令后，系统会提示输入数据库密码，输入完成后即可生成对应的 SQL 备份文件。

-u 后面填写数据库用户名（例如 root），-p 表示随后输入密码（不建议把密码直接写在命令里，比如 -p123456）
mydb 是需要备份的数据库名称，数据库必须存在，否则会报错 mysqldump: Got error: 1049: Unknown database 'mydb'
重定向符号 > 一定不能省略，否则导出的内容会直接打印到终端，既无法正常保存，也不利于后续恢复
目标备份文件所在路径必须可写，例如 /backup/mydb_$(date +%F).sql，同时建议按日期命名，避免旧备份被覆盖

为什么加 `--single-transaction` 很关键

如果你的表使用的是 InnoDB 引擎（也是 MySQL 的常见默认引擎），那么在执行 mysqldump 备份时，不加这个参数可能会触发全局读锁或逐表锁，进而影响写入操作，尤其对在线业务系统来说影响明显。

--single-transaction 会利用 MVCC 机制，在一致性事务快照中读取数据，从而实现备份过程尽量不锁表
不过这个参数只对 InnoDB 表有效；如果是 MyISAM 表，仍然可能发生锁表，这种情况下就要考虑 mysqlhotcopy 或在业务低峰期停写后再备份
如果备份过程中遇到错误 mysqldump: Got error: 1146: Table 'xxx' doesn't exist，通常说明导出期间有表被删除了，而加上 --single-transaction 往往可以显著降低这类问题出现的概率

常见坑：备份文件没数据 or 恢复失败

很多时候并不是 MySQL 备份命令本身有问题，而是几个容易忽略的细节导致了备份无效或恢复报错：

忘记加 --add-drop-table：恢复数据库时如果旧表仍然存在，执行 CREATE TABLE 时就会报错 Table 'xxx' already exists
使用 gzip 压缩却没改扩展名：例如写成 mysqldump -u root -p mydb | gzip > backup.sql，实际上得到的是压缩文件，但后缀仍是 .sql，后续恢复时很容易失败
备份时用了 --routines，但目标恢复库没有开启 log_bin_trust_function_creators=1：导入存储过程或函数时可能报错 ERROR 1418 (HY000)
正确的还原命令是 mysql -u root -p mydb < backup.sql；如果误写成 mysql -u root -p < backup.sql，就可能把 SQL 语句错误导入到 information_schema，后果非常严重

备份后该立刻验证什么

做完数据库备份后，不要等到真正需要恢复时才去检查文件是否可用，那时候往往已经太迟。

先用 head -20 backup.sql 检查文件开头是否包含 CREATE DATABASE 或 USE `mydb`，确认不是空文件，也不是权限报错日志
再统计行数：grep -c "INSERT INTO" backup.sql，至少应该看到非零结果（空库除外），这样才能说明导出中确实包含数据
可以任选一张小表，手动抽取几条记录进行比对：mysql -u root -p -Nse "SELECT * FROM mydb.users LIMIT 3" > live.txt，然后从 backup.sql 中执行 grep "INSERT INTO.*users" | head -3 简单核对内容
最稳妥的方式是真正恢复一次到测试库：先创建 mydb_test，再执行 mysql -u root -p mydb_test < backup.sql，最后通过 SELECT COUNT(*) FROM mydb_test.users 检查数据量是否一致