mysqldump 是最直接、最稳妥的单库备份方式，适用于≤50GB 的 InnoDB 数据库；核心命令为 mysqldump -u root -p mydb > mydb_backup.sql，需加 --single-transaction 避免锁表，注意 --add-drop-table、gzip 后缀、权限及还原验证。
mysqldump 是最直接、最稳妥的方式，只要数据库不大于 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 引擎（默认），不加这个参数，mysqldump 可能触发全局读锁或逐表锁，导致备份期间写操作卡住——尤其在线业务不能忍。
-
--single-transaction利用 MVCC，在事务快照中读取数据，全程不锁表 - 但只对 InnoDB 有效；MyISAM 表仍会锁，这时得考虑
mysqlhotcopy或停写 - 如果备份时遇到错误
mysqldump: Got error: 1146: Table 'xxx' doesn't exist，说明备份中途有表被删了，加了--single-transaction能大幅降低这类风险
常见坑：备份文件没数据 or 恢复失败
不是命令敲错，就是几个细节没注意：
- 忘记加
--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 是对的；写成 <code>mysql -u root -p 就会把所有语句塞进 <code>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 ，再 <code>SELECT COUNT(*) FROM mydb_test.users看是否一致
真实场景里，mysqldump 的可靠性取决于你有没有盯住这几个点：锁行为、文件完整性、还原上下文。漏掉任何一个，备份就只是“看起来存在”的文件。
