Linux 服务器导出 MySQL / PostgreSQL 数据入门操作清单

当我们在工作里听到一句话：

帮我把真实数据库导出来。

很多小白第一反应是紧张，因为这听起来不像“查一条 SQL”，而更像是在做一件有风险的运维操作。

这篇文章不追求讲所有数据库理论，而是专门帮你建立一个实用认知：

在 Linux 服务器上导出 MySQL / PostgreSQL 数据时，你到底要准备什么、怎么做、导出后文件应该怎么保存。

我会把重点放在你最容易忽视、但在真实工作里最容易出问题的部分：

导出文件保存到哪里
文件名怎么起
是否要压缩
怎么校验导出文件有没有问题
怎么安全地把文件传走

先用一句话理解“导出数据库”

数据库导出，本质上就是把数据库里的表结构、数据，或者其中一部分内容，转成一个可保存、可传输、可恢复的文件。

导出结果常见可能是：

.sql
.dump
.backup
.csv
.tar.gz

导出不等于“随便复制一份文件”。
它通常需要：

正确的数据库权限
合适的导出工具
足够的磁盘空间
明确的保存路径
安全的传输方式

先分清你到底要导出什么

在动手之前，先确认需求，不然后面很容易导错。

常见有四种情况：

1. 导出整个数据库

适合：

迁移环境
整体备份
测试环境还原

2. 导出指定几张表

适合：

只排查某一块业务
只需要局部数据
降低文件体积

3. 只导出表结构

适合：

看库表设计
建空库
做结构评审

4. 只导出表数据

适合：

数据迁移
数据分析
问题排查

如果这一步不问清楚，你很可能会把整库导出来，既浪费时间，也增加敏感数据泄露风险。

前置条件清单

在 Linux 服务器上导出数据库，通常需要先确认这些前置条件。

1. 你知道数据库类型

最常见是：

MySQL
PostgreSQL

因为它们对应的导出工具不一样：

MySQL 常用 mysqldump
PostgreSQL 常用 pg_dump

2. 你有服务器登录权限

你至少得能：

SSH 登录 Linux 服务器
切到合适目录
看磁盘空间
创建导出目录

3. 你有数据库连接信息

至少要知道：

主机地址
端口
用户名
密码
数据库名

4. 你有足够权限

需要确认自己是否有：

查询权限
导出权限
保存文件到目标目录的权限

5. 你知道导出文件可能很大

这点非常重要。

很多问题不是导出命令本身错了，而是：

磁盘空间不够
导出文件写到错误目录
导出了一半把系统盘写满

所以导出前一定先看空间。

例如：

df -h

这条命令能让你大致看到各挂载点剩余空间。

导出前最该先想清楚的：文件保存策略

对于小白来说，真正危险的往往不是“不会导出命令”，而是“导出出来不知道放哪”。

所以建议在执行导出前，先确定这四件事：

保存目录
命名规则
是否压缩
如何校验和传出

下面分别讲。

一、导出文件保存到哪里

原则：不要随手导出到当前目录，更不要直接丢到系统关键目录。

更稳妥的方式是专门建一个导出目录。

例如：

mkdir -p /data/db_exports

或者：

mkdir -p /home/your_user/db_exports

这类目录更适合临时保存导出文件。

不建议随便导出的地方

/
/etc
/usr
/var 下不清楚用途的目录
数据库程序自己的运行目录

更推荐的保存目录特点

你有写权限
空间足够
用途明确
方便后续压缩和传输

一个实用建议

可以按日期建子目录：

mkdir -p /data/db_exports/2026-07-09

这样后续更容易管理。

二、导出文件怎么命名

命名混乱，会让后续交接非常痛苦。

建议文件名至少包含这些信息：

数据库类型
库名
导出范围
日期时间

例如：

mysql_order_prod_full_20260709_103000.sql
postgres_user_center_table_account_20260709_104500.dump

如果是压缩后，可以是：

mysql_order_prod_full_20260709_103000.sql.gz
postgres_billing_partial_20260709_104500.dump.gz

命名的价值在于：

一看就知道是什么
方便查历史
不容易覆盖旧文件

三、导出后要不要压缩

很多情况下，建议压缩。

原因很简单：

文件更小
传输更快
节省空间

常见压缩方式：

gzip filename.sql

压缩后文件会变成：

filename.sql.gz

如果你想保留原文件，也可以：

gzip -c filename.sql > filename.sql.gz

什么时候更建议压缩

文件很大
需要下载到本地
需要发给别人
需要长期保留一小段时间

四、导出后怎么确认文件不是坏的

这一步很多人会漏掉。

你不能只看到“命令执行完了”就默认没问题。
至少要做基本检查。

1. 看文件是否真的生成

ls -lh /data/db_exports/2026-07-09

重点看：

文件在不在
文件大小是否合理

2. 看文件大小是否异常

如果一个平时几百 MB 的导出结果，这次只有 2 KB，那大概率有问题。

3. 看文件头部内容

对 SQL 文件可以简单看前几行：

head -n 20 filename.sql

你通常能看到：

导出注释
建表语句
INSERT 语句

如果里面全是报错信息，那肯定不对。

4. 计算校验值

如果文件后面要传走，建议顺手算一个 hash：

sha256sum filename.sql.gz

这样有两个好处：

方便确认传输后文件是否损坏
方便交付时做一致性核对

五、导出文件怎么安全传出

这是“保存部分”之后最关键的一环。

常见错误做法包括：

直接发聊天工具
随手丢到公开目录
放到 everyone 可读的共享盘
明文长期留在服务器

更稳妥的思路是：

导出到专用目录
压缩
校验
通过安全通道传输
确认接收完成后清理服务器临时文件

常见安全传输方式

scp
sftp
堡垒机文件传输
内部安全文件系统
加密后再传输

例如通过 scp 拉到本地：

scp your_user@server:/data/db_exports/2026-07-09/mysql_order_prod_full_20260709_103000.sql.gz .

如果数据敏感怎么办

真实数据库很可能包含：

手机号
身份证号
邮箱
用户行为数据
内部业务数据

所以在导出前还应该确认：

是否允许导出真实数据
是否需要脱敏
是否只能导出部分字段
是否要加密压缩包

这一步不是技术细节，而是安全边界。

MySQL 导出入门操作清单

下面给一个适合入门理解的基本流程。

1. 先建目录

mkdir -p /data/db_exports/2026-07-09
cd /data/db_exports/2026-07-09

2. 导出整个库

mysqldump -h 127.0.0.1 -P 3306 -u db_user -p database_name > mysql_database_name_full_20260709_103000.sql

执行后会提示输入密码。

说明

-h：数据库地址
-P：端口
-u：用户名
-p：输入密码

3. 导出指定表

mysqldump -h 127.0.0.1 -P 3306 -u db_user -p database_name table_a table_b > mysql_database_name_tables_20260709_103500.sql

4. 只导出结构

mysqldump -h 127.0.0.1 -P 3306 -u db_user -p --no-data database_name > mysql_database_name_schema_20260709_104000.sql

5. 导出后压缩

gzip mysql_database_name_full_20260709_103000.sql

6. 校验

ls -lh
sha256sum mysql_database_name_full_20260709_103000.sql.gz

PostgreSQL 导出入门操作清单

PostgreSQL 常用 pg_dump。

1. 先建目录

mkdir -p /data/db_exports/2026-07-09
cd /data/db_exports/2026-07-09

2. 导出整个库

pg_dump -h 127.0.0.1 -p 5432 -U db_user -d database_name -f postgres_database_name_full_20260709_110000.sql

执行时通常会要求输入密码，或者依赖环境配置。

3. 使用自定义格式导出

pg_dump -h 127.0.0.1 -p 5432 -U db_user -d database_name -Fc -f postgres_database_name_full_20260709_110500.dump

这里的：

-Fc 表示自定义格式

这种格式常用于后续恢复和迁移。

4. 导出指定表

pg_dump -h 127.0.0.1 -p 5432 -U db_user -d database_name -t table_a -t table_b -f postgres_database_name_partial_20260709_111000.sql

5. 导出后压缩

如果你导出的是 .sql：

gzip postgres_database_name_full_20260709_110000.sql

如果是 .dump，也可以视情况再压缩。

6. 校验

ls -lh
sha256sum postgres_database_name_full_20260709_110500.dump

保存部分最容易踩的坑

这部分我单独列出来，因为工作里真正出事的 often 不在导出命令本身。

1. 导出到系统盘，结果把磁盘打满

比如误导出到：

/root
/var
当前不明目录

如果文件很大，容易把系统盘写爆，影响其他服务。

所以导出前先：

pwd
df -h

2. 文件名没有时间戳，被新文件覆盖

如果你总叫：

backup.sql

那下一次就很可能覆盖掉上一次。

3. 只导出不校验，结果拿到的是不完整文件

命令成功退出，不等于导出的内容一定符合预期。
至少要做：

文件存在检查
文件大小检查
hash 校验

4. 敏感数据导出后长期留在服务器

这很常见，也很危险。

如果导出只是为了临时排查或交付，完成后应该按流程处理：

删除临时文件
或移交到安全存储
或做权限收口

5. 通过不安全方式传播

真实库导出文件不是普通资料。
不要默认它可以像截图、文档一样到处发。

一份适合小白记忆的总清单

Linux 导出数据库前
1. 确认导出范围：整库 / 表 / 结构 / 数据
2. 确认数据库类型：MySQL / PostgreSQL
3. 确认账号权限和连接信息
4. 确认导出目录
5. 确认磁盘空间

执行导出时
6. 使用对应工具：mysqldump / pg_dump
7. 文件名带上库名、范围、时间
8. 导出到专用目录

导出完成后
9. 看文件是否存在
10. 看文件大小是否合理
11. 必要时压缩
12. 计算 sha256
13. 通过安全通道传出
14. 按流程清理服务器临时文件

最后怎么理解“导出保存部分”为什么这么重要

很多人以为导出数据库最难的是命令。
其实在真实工作里，更容易出问题的是“导出后的落地管理”。

更准确地说，导出操作通常不只是：

把数据库内容导出来

而是完整的一条链路：

明确范围 -> 执行导出 -> 保存到合适目录 -> 压缩 -> 校验 -> 安全传输 -> 按流程清理

当你把这条链路建立起来后，哪怕你还是初学者，也已经比“只会敲导出命令”的状态稳很多了。

如果后面继续深入，这篇文章最适合往下接的主题通常是：

mysqldump 常用参数详解
pg_dump 与恢复命令配套说明
Linux 服务器安全传文件方式
真实库导出时的数据脱敏流程