分库独立导出需为每个库单独调用 mysqldump 或 pg_dump：MySQL 用循环执行 mysqldump -B "$db" -r "${db}_$(date +%F).sql"，PostgreSQL 用 psql -t -c "SELECT datname..." 动态获取库名并 pg_dump -d "$db" -f "${db// /\_}.sql"，均需引号保护变量、避免覆盖、控制并发≤2、加 set -e 确保失败中断。
mysqldump 一次导出多个库时如何避免混在一个文件里
很多朋友习惯用 mysqldump --databases db1 db2 db3 来一次性备份多个库，结果发现所有数据都被塞进了一个巨大的 SQL 文件里，中间仅仅用 create database 和 use 语句隔开。这种做法在恢复时其实埋了不少坑：万一目标实例里已经存在同名库，或者当前连接用户的权限不足，整个恢复过程就可能卡在半路，进退两难。
所以，想要真正实现“分库独立文件”，没有捷径可走，必须让每个数据库都走一遍独立的 mysqldump 进程。这里有个常见的误解，以为加上 --result-file 参数就能分流，其实这个参数只控制单次命令的输出路径，对合并多个库的操作完全无效。
- 正确的做法是借助 shell 循环，每次调用
mysqldump时只传入一个库名。 - 输出文件名必须包含库名变量，比如
db1_$(date +%F).sql，否则后一个库的备份会直接覆盖前一个，风险极高。 - 建议加上
--skip-comments选项，减少冗余注释，避免某些恢复工具误将注释里的USE语句当作命令来解析。 - 如果库名包含中划线、下划线这类特殊字符，
mysqldump本身是支持的，但在 shell 脚本里引用变量时，务必记得加上双引号："$db"。
PostgreSQL pg_dump 分库导出不写死库名的脚本写法
pg_dump 工具本身没有提供一键导出所有非系统库的开关，它的 -d 参数一次只能接受一个数据库。于是有人把命令硬写成 pg_dump -d db1 -f db1.sql && pg_dump -d db2 -f db2.sql 这样一长串。看起来能跑通，可一旦数据库列表有变动，维护起来就成了噩梦。
更稳健的方式，是动态查询 pg_database 系统表，过滤掉模板库后再进行循环导出。这里有两个细节需要特别注意：一是必须排除 template0 和 template1；二是连接参数（比如 -U、-h）最好统一放在循环外部定义，别在每次循环里重复写，既啰嗦又容易出错。
- 使用
psql -t -c "SELECT datname FROM pg_database WHERE datistemplate = false AND datname NOT IN ('postgres')"来获取需要备份的库名列表。 - 在循环体内，执行
pg_dump -U $USER -h $HOST -d "$db" -f "$db.sql"，记住，$db变量两端必须加上双引号。 - 加上
--no-owner和--no-privileges选项是个好习惯，可以避免在恢复时因为目标环境用户不存在而报错。 - 如果某个库特别大，导出很慢，可以尝试加上
--jobs=2启用并行导出，但要注意，这只是针对单个库内部的并行，并非跨库并行。
备份脚本里怎么处理库名中的空格或连字符
MySQL 允许库名包含空格（创建时需要用反引号包裹），PostgreSQL 也允许使用连字符（创建时用双引号包裹）。但问题来了，在 shell 脚本里，如果直接把这些包含特殊字符的库名当作变量展开，命令执行往往会直接崩溃。典型的错误就像 mysqldump -B `dbname with space`，系统会报 Unknown database——这其实不是数据库不认识它，而是 shell 把空格当成了命令参数的分隔符，把库名给“切碎”了。
根本的解决方案不是去修改数据库里的库名，而是确保在命令执行时，变量值能被原封不动地传递过去。关键在于理解引号的嵌套和转义层级：外层用双引号保护变量不被 shell 解析，内层可能存在的反引号或双引号，则交给数据库客户端自己去处理。
- MySQL 场景：使用
mysqldump -B "$db" -r "${db}_backup.sql"。即使$db的值本身包含反引号（比如`my db`），这样写也能正确传递。 - PostgreSQL 场景：使用
pg_dump -d "$db" -f "${db// /_}.sql"。这里用了一个小技巧${db// /_}，把库名中的空格替换成下划线，主要是为了避免生成包含空格、可能引发问题的文件名。 - 一个通用的好建议：所有输出文件路径都尽量使用绝对路径。如果使用相对路径，当脚本通过 cron 定时任务执行时，工作目录可能不是你预想的那一个，文件很容易被写到莫名其妙的地方去。
并发导出多个库时磁盘 I/O 和连接数的实际瓶颈
听起来很美好：用 & 符号在后台并发跑 5 个 mysqldump，备份速度岂不是能翻几倍？但现实往往很骨感，真正的瓶颈通常会卡在磁盘写入速度上，或者把数据库的连接池直接打满。尤其是在使用共享宿主机的云数据库服务时，默认的 max_connections 可能只有 151，5 个库同时 dump 就占去 5 个连接，如果业务本身连接数就高，还可能意外触发慢查询甚至导致锁表。
因此，一个更现实、更平衡的策略是：将并发数控制在 ≤ 2，并且配合压缩进行流式写入。千万别盲目相信“进程越多越快”，对于 I/O 密集型任务，过多的并发反而会因磁盘磁头频繁寻道而导致整体速度下降。
- 对于 MySQL，强烈推荐在导出 InnoDB 表时加上
--single-transaction参数。它通过开启一个一致性快照来获取数据，比--lock-tables那种锁表的方式对线上业务的影响要小得多。 - 输出直接通过管道交给
gzip压缩：mysqldump db1 | gzip > db1.sql.gz。这不仅能大幅节省磁盘空间，还能减少实际的磁盘写入量（写放大）。 - 对于 PostgreSQL，可以考虑使用
-Fc（自定义格式）替代默认的纯 SQL 文本格式。这种格式体积更小、恢复更快，但缺点是必须使用pg_restore工具来读取。 - 务必在脚本的开头加上
set -e命令。这样，当任何一个mysqldump或pg_dump命令执行失败时，整个脚本就会立即停止，防止后续的备份操作继续覆盖或写入不完整的文件。
还有一个极易被忽略的细节：时间戳的精度。如果在同一秒内启动多个 dump 进程，按照常规的 $(date +%F) 生成的文件名就会重复，导致文件被覆盖。哪怕只是毫秒级的冲突，也需要防范。可以采用 $(date +%F_%H-%M-%S-%N | cut -c1-17) 来截断纳秒部分，或者更简单地，在文件名中嵌入进程号 $$，从而彻底避免重名。
