生产环境备份单库必须加--single-transaction、--routines、--triggers、--events，否则可能无法还原、锁表或缺失存储过程等；不加--databases则还原时需手动建库；推荐用~/.my.cnf存密并chmod 600。
mysqldump 备份单库，**不是简单敲个命令就完事**——漏掉关键参数，备份出来可能无法还原、会锁表、或缺失存储过程和触发器。生产环境必须带 --single-transaction 和 --routines --triggers --events，否则恢复时大概率报错。
备份单库必须加 --single-transaction
InnoDB 表默认不加这个参数，mysqldump 会隐式执行 FLUSH TABLES WITH READ LOCK，导致整个库只读，业务写入卡住。加上后，它利用 MVCC 快照保证一致性，全程不锁表。
注意：--single-transaction 对 MyISAM 表无效，且要求事务隔离级别为 REPEATABLE READ（默认就是）。如果库混用引擎，得额外评估风险。
- ✅ 正确写法：
mysqldump -uroot -p --single-transaction test_db > test_db.sql - ❌ 危险写法：
mysqldump -uroot -p test_db > test_db.sql（无热备，锁表）
--databases 参数决定还原是否要手动建库
不加 --databases，导出的 SQL 文件里没有 CREATE DATABASE 和 USE 语句；还原时目标库必须已存在，否则报错 Unknown database 'test_db'。
加了 --databases，文件开头就有建库和选库语句，直接 mysql -uroot -p 就能全量还原，适合迁移或快速重建。
- ✅ 想还原省心：用
--databases test_db - ✅ 想只导数据结构（比如做 schema diff）：加
--no-data，但别漏--databases，否则没CREATE DATABASE - ⚠️ 注意：加了
--databases后，参数顺序不能错——test_db必须紧跟在它后面，不能写成--databases -uroot -p test_db
压缩备份是线上刚需，别等磁盘爆了才想起来
一个 5GB 的库，mysqldump 导出后约 3–4GB，再经 gzip 压缩通常只剩 600–900MB。不压缩，备份文件堆积快，传输慢，清理也麻烦。
用管道压缩时，mysqldump 输出直接进 gzip，不落地临时文件，内存占用可控。但要注意：压缩后文件后缀得是 .sql.gz，别写成 .gz，否则还原时容易搞混。
- ✅ 推荐写法：
mysqldump -uroot -p --single-transaction --routines --triggers --events --databases test_db | gzip > test_db_$(date +%Y%m%d).sql.gz - ⚠️ 坑点：
gzip崩溃会导致备份中断且无提示，建议加set -o pipefail到脚本中捕获错误 - ⚠️ 还原压缩包不能直接
mysql ，得先 <code>zcat xxx.sql.gz | mysql -uroot -p test_db
密码交互输入比明文安全，但自动化场景得换方案
写 -p 不跟密码，执行时弹出 Enter password: 提示，避免密码出现在 ps aux 或 bash history 里。这是开发/运维手工操作的底线安全习惯。
但定时任务或 CI/CD 脚本里没法交互输入，硬塞明文密码极不推荐。正确做法是用 MySQL 配置文件 ~/.my.cnf：
[client] user=root password=your_secure_password host=localhost
然后命令简化为：mysqldump --single-transaction --databases test_db > test_db.sql。记得 chmod 600 ~/.my.cnf，否则 mysqldump 会拒绝读取。
另外，--defaults-extra-file 可指定非标准路径的配置文件，适合多环境切换。
gzip -t xxx.sql.gz 和 head -20 xxx.sql 看一眼有没有 CREATE DATABASE 和 INSERT，花十秒的事，能省几小时排查时间。
