--databases参数可一次性备份多个指定数据库，库名间用空格分隔，生成含CREATE DATABASE和USE语句的SQL文件，恢复时无需手动建库；推荐加--single-transaction --routines --triggers --events及时间戳与gzip压缩。
直接用 mysqldump 的 --databases 参数就能同时备份多个数据库，不需要写脚本或循环——只要权限够、库名对，一条命令就导出结构+数据，恢复时也无需手动建库。
用 --databases 一次性备份指定多个库
这是最常用、最稳妥的多库备份方式。关键点是：--databases 后面跟的每个库名之间用空格分隔，不能用逗号，也不能加引号（除非库名含空格或特殊字符）。
mysqldump -uroot -p --single-transaction --routines --triggers --events --databases test log shop > multi_backup.sql- 执行后会提示输入密码；生成的 SQL 文件里包含
CREATE DATABASE IF NOT EXISTS和USE语句，恢复时直接mysql -u... 即可 - 如果某个库不存在，整个命令会失败并报错，比如
mysqldump: Got error: 1049: Unknown database 'xxx'，不会跳过错误库 - 不推荐在命令行明文写密码（如
-p123456），容易被ps看到；用-p不带值，交互输入更安全
备份所有数据库用 --all-databases
和 --databases 行为不同：--all-databases 会把 mysql、information_schema 等系统库也一并导出，恢复时可能覆盖用户权限配置，生产环境慎用。
mysqldump -uroot -p --single-transaction --routines --triggers --events --all-databases > full_backup.sql- 若只想备份业务库，排除系统库，必须用脚本动态获取库名列表，不能靠
--all-databases -
--all-databases隐含--databases行为，所以恢复时也不需提前建库 - 注意：
performance_schema和sys库内容是运行时生成的，备份意义不大，但--all-databases会包含它们
带时间戳和压缩的实操建议
线上备份必须防止文件覆盖、节省磁盘空间，这两步不能省。
- 文件名加时间戳：
mysqldump -uroot -p --databases a b c > backup_$(date +%Y%m%d_%H%M%S).sql - 边导出边压缩：
mysqldump -uroot -p --databases a b c | gzip > backup_$(date +%Y%m%d_%H%M%S).sql.gz - 压缩后体积通常能降到 1/3～1/5，但恢复时得先
gunzip或用管道：gunzip - 别忘了检查磁盘空间——
mysqldump是先全量生成 SQL 再写入磁盘（或管道），内存和临时空间压力不小
常见错误和权限坑点
很多“备份成功但恢复失败”问题，根源不在命令本身，而在权限或参数缺失。
- 报错
Access denied for user 'xxx'@'%' to database 'yyy'：说明该用户对某个库没有SELECT权限，哪怕只读也要显式授权：GRANT SELECT ON yyy.* TO 'xxx'@'%'; - 备份文件里没触发器/存储过程：漏了
--routines或--triggers参数；--events同理，定时事件默认不导出 - 恢复时报
Unknown database：不是备份问题，而是恢复时没指定目标库（如mysql -u... ），而文件里又没 <code>CREATE DATABASE——确认是否用了--databases或--all-databases - 密码含特殊字符（如
@、$）导致命令解析失败：改用~/.my.cnf配置文件存凭证，避免命令行传参
真正麻烦的不是命令怎么写，而是备份后没人验证能否还原、没人定期清理旧文件、没人监控磁盘是否快满了——这些比语法细节更容易让一次备份失效。
