MySQL 多库导出须加 --databases 参数，否则后续库名被误作表名报错；pg_dump 不支持单命令多库，需分导后 cat 拼接并统一选项；异构数据库不可混入同一文件恢复。
MySQL 多库 mysqldump 一次性导出的正确写法
直接用 mysqldump 导出多个数据库，不能简单空格拼库名——那样会触发「unknown database」错误，因为默认只认第一个参数为数据库名，其余被当表名处理。
必须显式加 --databases 参数，后面跟所有目标库名（空格分隔）：
mysqldump -u root -p --databases db_a db_b db_c > all_dbs.sql
-
--databases是开关，不是可选修饰；漏掉它，db_b就会被当成db_a下的表，报错Unknown table 'db_b' - 如果某个库不存在，
mysqldump默认继续导出其余库，但会输出警告到 stderr；加--force可抑制中断，但别依赖它掩盖权限或连通性问题 - 不建议在命令行里写密码（
-p'xxx'），容易泄露；改用配置文件~/.my.cnf或--defaults-extra-file
PostgreSQL pg_dump 合并导出多个数据库要分两步
pg_dump 本身不支持一次连多个数据库——每个数据库是独立连接上下文，pg_dump 只能单库导出。所谓“合并”，本质是多次导出 + 手动拼接，但要注意顺序和兼容性。
最稳妥的做法是分别导出再 cat 拼接，并确保都用 --clean 和 --if-exists：
pg_dump -U postgres --clean --if-exists db_a > dump.sql pg_dump -U postgres --clean --if-exists db_b >> dump.sql
- 不能用
pg_dumpall替代：它导出的是集群级对象（roles、tablespaces），不含用户数据，且强制包含所有数据库，无法按需筛选 - 拼接前确认各库导出时用了相同
--no-owner和--no-privileges，否则恢复时可能因 owner 不一致失败 - 如果某库含大对象（LOB），务必加
--large-objects（默认已启用），否则二进制数据会丢失
跨数据库类型合并备份？别硬凑，先想清楚恢复路径
把 MySQL 和 PostgreSQL 的数据塞进同一个 SQL 文件，技术上可以（比如用 cat 拼），但实际毫无意义——恢复时根本没法统一执行。SQL 语法、事务控制、注释格式全都不兼容。
- 混合导出唯一合理场景是归档用途，且必须人工标注分隔块，例如在每段开头加
-- DATABASE: mysql/db_a --这类注释 - 自动恢复脚本无法可靠识别这种混合文件；生产环境严禁用一个文件承载异构数据库备份
- 真正需要“统一管理”的，应该用外部元数据标记：每个库单独导出 + 统一命名规则（如
20240615-mysql-db_a.sql）+ 清单文件manifest.json
大库合并导出时磁盘和锁的风险点
多库导出不是简单的 I/O 叠加，而是一次性拉长了锁持有时间与磁盘写入压力。尤其对 MySQL 的 MyISAM 表或未加 --single-transaction 的 InnoDB 库，风险更高。
- 加
--single-transaction仅对 InnoDB 有效；MyISAM 仍会全程锁表，合并导出等于延长整体只读窗口 - 导出文件直写到系统盘（如
/tmp）容易撑爆空间；务必用--result-file=/backup/all.sql指向专用挂载盘 - 超过 50GB 的导出，建议拆成单库独立任务 + 并发控制（如
parallel限 2 个进程），避免单点失败导致全量重跑
最常被忽略的一点：备份文件的时间戳和校验值必须和导出命令一起记录。光有 all_dbs.sql 没用，没人知道它对应哪一刻的集群状态，也没人敢信它没在写入中途被截断。
