mysqldump裸用-u -p db_name不可靠，必须加--single-transaction（InnoDB无锁一致性快照）、--routines（导出存储过程/函数）、--triggers（导出触发器），并配绝对路径与时间戳文件名。
mysqldump 是备份 MySQL 单个指定数据库最直接、最可控的方式。但直接写 mysqldump -u root -p mydb > backup.sql 很容易在生产环境出问题——不是数据不一致，就是恢复时缺关键对象。
为什么不能裸用 mysqldump -u -p db_name
这个命令能跑通，但默认行为对生产极不友好：--single-transaction 不开，InnoDB 大表会锁住写入；--routines 和 --triggers 不加，存储过程、函数、触发器全丢；没带时间戳，反复执行就覆盖；输出路径没指定，文件可能生成在某个临时目录里，找都找不到。
mysqldump 必加的三个参数
真正可用的最小安全组合是：
-
--single-transaction：对 InnoDB 表启用一致性快照，全程不锁表（MyISAM 仍会锁，但多数场景已不用） -
--routines：导出存储过程和函数（否则mysql -e "CALL proc_name()"会报错 Unknown procedure） -
--triggers：导出触发器（比如订单表上的自动更新库存逻辑）
示例命令：mysqldump -uroot -p --single-transaction --routines --triggers myapp_db > /backup/myapp_db_$(date +%Y%m%d_%H%M).sql
备份文件名必须带时间戳，且路径要绝对
不带时间戳的备份等于没备——cron 每天跑一次，第二天就覆盖掉前一天的；相对路径如 backup.sql 在不同工作目录下会写到不同地方，运维排查时根本不确定文件在哪。
- 用
$(date +%Y%m%d_%H%M)精确到分钟，避免同天多次备份冲突 - 路径写成绝对路径，比如
/backup/或/data/backups/mysql/，别依赖当前目录 - 如果磁盘空间紧张，可加
| gzip，但必须确保--single-transaction已启用，否则压缩过程中数据还在变
验证备份是否真的可用
备份完成不等于能恢复。光看文件大小没用，得确认内容有效：
- 用
head -n 20 /backup/myapp_db_20260702_0230.sql查看开头，应有CREATE TABLE和INSERT语句 - 检查是否有
DELIMITER $$和CREATE PROCEDURE块（证明--routines生效） - 还原前先试运行：
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS test_restore;"，再mysql -u root -p test_restore ，看是否报错
最容易被忽略的是：备份时用了 --databases，还原时却忘了 CREATE DATABASE 步骤——其实单库备份默认不含建库语句，必须手动创建目标库再导入。
