MySQL导出数据全攻略：从mysqldump到CSV乱码与工具避坑

我上一家公司有个从 MySQL 往数仓导数的需求，四十多张表，数据量不算大但字段刁钻，负责的同事折腾了两天，最后导出的 CSV 在报表平台里打开全是乱码，主键还丢了，经理开周会时问了一句“这数据到底是谁导的”，会议室安静了好一会儿。

那次之后我花了不少时间把 MySQL 导出数据这件事从头到尾捋了一遍。说实话，这个操作看起来简单，真要拿到生产环境里用，坑比想象中多得多。不管是日常备份、数据迁移、报表分析还是给客户交付数据，只要涉及“把数据从 MySQL 里弄出来”，你就需要一套完整的判断逻辑：用什么工具、以什么格式、走什么通道、注意什么坑。这篇文章就把我在实际工作中趟过的路径完整梳理一遍，希望能帮正在被导出数据折磨的同学省点时间。

1. 拿到导出需求，先分清你要的是哪种“导出”

很多同学一接到需求就直接打开 Navicat 点“转储 SQL 文件”，这个习惯其实挺危险的。MySQL 的“导出数据”在不同场景下是完全不同的操作，选错方案轻则浪费时间，重则数据丢失。

我一般会把导出需求先分成下面四类：

这里面的核心判断标准是：对方拿到数据后打算怎么用。如果是 DBA 要把库还原起来，那就老老实实用 SQL 文件；如果是业务同事要透视表，那就给 CSV 或 Excel；如果是数据平台要消费，那就要考虑 CSV 格式的编码、分隔符、空值处理这些细节。

有一个很典型的反面案例：有人为了图方便，用 Navicat 把一张 200 万行的表导出成了 Excel。结果 Excel 最多支持 104 万行左右的数据，文件直接截断，业务部门拿到数据后发现少了一半，还以为是系统漏数据了。这种问题的根源不在于工具，而在于没有提前想清楚“导出后数据去哪、怎么用”。

还有一点容易忽略：导出不只是掏数据，还要考虑数据的“可还原性”。如果是备份场景，只导出表数据而丢了触发器、存储过程、自定义函数，恢复的时候就会出大事。这类元信息在 mysqldump 里是要靠参数控制的，后面我会专门展开讲。

2. 命令行导出为什么依然是首选：mysqldump 参数逐个拆解

不管 GUI 工具多方便，我依然认为 mysqldump 是 MySQL 导出场景里最可靠的方案。原因有三：第一，它不依赖任何第三方客户端，MySQL 装好就有；第二，它的参数非常细，可以精确控制导出范围；第三，脚本化之后可以做定时备份，完全无人值守。

2.1 最常用的几种导出姿势

先说最基础的，按导出范围从小到大排列：

bash复制# 导出单张表（包含表结构和数据）
mysqldump -uroot -p mydb users > users.sql

# 导出单张表，只要结构不要数据
mysqldump -uroot -p -d mydb users > users_schema.sql

# 导出整个库
mysqldump -uroot -p mydb > mydb_full.sql

# 导出多个库
mysqldump -uroot -p --databases db1 db2 > dbs.sql

# 导出整个实例的所有库
mysqldump -uroot -p --all-databases > all_dbs.sql

这里注意 -d 参数，它表示只导出结构（no data），很多同学要迁移表结构的时候忘了加这个参数，结果导出一大堆 INSERT 语句，文件体积暴增，完全没必要。

2.2 核心参数背后的原理

真正见功力的是下面这几个参数：

--single-transaction

这个参数对 InnoDB 表至关重要。它的原理是在导出前启动一个 REPEATABLE READ 事务，这样导出的数据是一致性快照，整个 dump 过程中不会锁表，业务可以继续读写。

bash复制mysqldump -uroot -p --single-transaction mydb > mydb.sql

如果不加这个参数，默认会锁表，生产环境表一锁，线上业务直接受影响。我见过有人凌晨三点跑 cron 备份结果把业务锁死的情况，就是因为漏了这个参数。

--set-gtid-purged=OFF

如果你用的 MySQL 5.7+ 并且开启了 GTID，导出文件里会带有 SET @@GLOBAL.GTID_PURGED 这类语句。这在主从复制环境里是必要的，但如果只是普通备份还原，这句反而会带来麻烦——还原时可能报 GTID 相关的错误。日常导出建议加上这个参数：

bash复制mysqldump -uroot -p --set-gtid-purged=OFF mydb > mydb.sql

--routines 和 --triggers

很多同学导完数据后说“我的存储过程去哪里了”，就是因为 mysqldump 默认不导出存储过程、函数和触发器。需要连同这些元信息一起导出时：

bash复制mysqldump -uroot -p --routines --triggers mydb > mydb_full.sql

2.3 生产环境推荐的标准导出命令

我在生产环境实际使用的命令长这样：

bash复制mysqldump -uroot -p \
  --single-transaction \
  --set-gtid-purged=OFF \
  --routines \
  --triggers \
  --default-character-set=utf8mb4 \
  --hex-blob \
  mydb > mydb_$(date +%Y%m%d).sql

简单解释一下：

• --default-character-set=utf8mb4：保证导出文件的字符集，避免乱码，这个后文有专题。
• --hex-blob：BLOB 二进制字段用十六进制形式导出，否则遇到特殊字节可能导致 SQL 文件损坏。

这套命令我用了很久，没出过岔子。当然，如果是超大库（几百 GB 级别），mysqldump 这种逻辑备份方式就不太合适了，物理备份（比如 Percona XtraBackup）才是正解，不过那是另一个话题了。

3. 可视化工具导出实测：Navicat、DBeaver、Workbench 的差异与坑

命令行虽好，但日常对接业务同事时，我经常得用可视化工具直接导出 Excel 或 CSV。工具选不好，同样会让你头大。

3.1 Navicat：功能全面但费用不低

Navicat 的“转储 SQL 文件”和“导出向导”是两种完全不同的路径。前者相当于包装了 mysqldump，后者才是真正给业务人员用的格式导出。

用 Navicat 导出 Excel 时，比较容易忽略的一个设置是“高级”选项卡里的编码。如果你用默认编码导出的 CSV 被 Excel 打开乱码，把编码改成“UTF-8”之后，再留意有没有设置 BOM 的选项。Navicat 在这方面做得算不错，但导出超大表时会比较吃内存，而且长时间导出容易崩溃。

3.2 DBeaver 导出没有主键 id 的问题

热搜词里“dbeaver导出数据没有主键id”这个问题，我确实遇到过，而且研究了一番才发现根因。

DBeaver 在导出查询结果或者数据表的时候，默认情况下会隐藏主键列。它认为主键属于“高级属性”，默认不展示也不导出。这导致很多人在 DBeaver 里看到了数据，导出 Excel 后却发现 id 列神秘消失。

解决办法有两种：

方法一：在导出配置里手动勾选

选择表后点击右键 → 导出数据 → 导出目标 选择 CSV/Excel → 在 表映射 那一步，展开字段列表，把被隐藏的主键字段手动勾选上。

方法二：调整 DBeaver 的全局设置

打开 窗口 → 首选项 → 数据库 → 数据编辑器 → 内容查看器，找到“在结果集中显示隐藏列”的选项，勾选“显示”。这样在查询结果里就能直接看到主键，导出自然也会带上。

这个方法对临时查询特别有用。我习惯一装完 DBeaver 就把这个选项打开，否则每次查完数据，id 字段总是莫名其妙消失，体验很差。

3.3 MySQL Workbench：官方免费但导出有局限

MySQL Workbench 的导出入口在Server菜单下的Data Export，它其实也是调用 mysqldump，所以功能和命令行基本一致。

但 Workbench 的 CSV 导出能力相对较弱。它的导出行功能只能导出当前查询结果集，而且对大结果集处理得不好，容易卡死。如果你只是用 Workbench 做日常开发、偶尔导出小量数据，那够用；但如果经常要导几万行以上的数据，还是建议用专门工具。

3.4 工具选择总结

4. 乱码问题的根因与排查链路：从字符集一路查到底

热搜里“mysql数据库导出数据乱码问题”那么多人搜，说明这是全行业都在痛的坑。乱码的根子不在导出那一步，而是从数据写入、存储、读取链路里任何一环字符集不一致都会造成。

4.1 先搞清楚字符集链路

MySQL 里字符集相关的变量有这几个：

sql复制SHOW VARIABLES LIKE 'character_set_server';      -- 服务端默认
SHOW VARIABLES LIKE 'character_set_database';     -- 当前库
SHOW VARIABLES LIKE 'character_set_client';       -- 客户端
SHOW VARIABLES LIKE 'character_set_results';      -- 返回结果
SHOW VARIABLES LIKE 'character_set_connection';   -- 连接层

字符集链路是这样的：客户端以 character_set_client 的编码发送 SQL → MySQL 在连接层转为 character_set_connection 处理 → 存储时按字段的字符集写入 → 返回结果时按 character_set_results 转出。

只要其中某一层不一致，数据就可能“货不对板”。最常见的场景是：数据库表是 utf8mb4，但连接的 client 编码是 latin1，那数据进去的时候就已经被转坏了，导出的时候再怎么设置也救不回来。

4.2 导出乱码的排查步骤

当导出文件出现乱码时，我有一套固定的排查链路：

第一步，先确认源数据有没有问题：

sql复制-- 直接在命令行查询某条记录，观察是否乱码
SELECT id, name, content FROM my_table WHERE id = 123;

如果终端直接查询就乱码，说明问题在源头或连接层；如果查询正常但导出文件乱码，说明问题在导出环节。

第二步，确认导出时的字符集参数：

bash复制# mysqldump 导出时显式指定 utf8mb4
mysqldump -uroot -p --default-character-set=utf8mb4 mydb > mydb.sql

第三步，检查导出后的文件编码：

bash复制# Linux 下查看文件编码
file mydb.sql

4.3 CSV 文件在 Excel 中乱码的关键细节

CSV 文件本身没有编码标记（BOM），Excel 在 Windows 上默认按本地 ANSI 编码（如 GBK）打开 UTF-8 文件，自然就乱码了。业界最常用的解决办法是：导出的 CSV 文件带 BOM 头（EF BB BF），这样 Excel 能识别这是 UTF-8 编码。

如果是用 MySQL 命令行导出 CSV，可以通过以下方式带上 BOM。

SELECT ... INTO OUTFILE 无法直接写 BOM，但可以先用 printf 生成带 BOM 的文件，再写入数据，或者用 sed 在文件开头插入 BOM：

bash复制# 先导出数据
mysql -uroot -p -e "SELECT * FROM mydb.users" > /tmp/users.csv

# 给文件加 BOM 头
sed -i '1s/^/\xEF\xBB\xBF/' /tmp/users.csv

用 DBeaver 导出时，在导出配置里找到编码设置，选择 UTF-8，部分版本还会有一个 包含 BOM 的选项，勾上就行。

4.4 预防乱码的最佳实践

要彻底少踩乱码的坑，建议从这几个方面一起抓：

• 建表统一用 utf8mb4，MySQL 8.0 默认就是这个，5.7 需要显式指定。
• 连接字符串里显式设置编码，比如 JDBC 连接加 characterEncoding=utf8。
• 导出文件统一规范：SQL 文件用 UTF-8，CSV 给 Windows 用户时带 BOM。
• 所有导出脚本里显式写明 --default-character-set=utf8mb4，不依赖服务器默认值。

5. 进阶导出场景：大数据量 CSV、Sqoop 对接与报表平台的那些坑

当导出量到了千万行级别，或者要从 MySQL 往 Hadoop/数仓平台导数据时，前面说的工具就有点力不从心了。这里说几个我实际踩过的进阶场景。

5.1 千万级数据用 SELECT INTO OUTFILE

MySQL 提供了 SELECT ... INTO OUTFILE 语法，可以直接在服务端把查询结果写成一个文本文件，速度远快于 GUI 工具的逐行导出，因为不需要经过客户端网络传输。

sql复制SELECT id, name, created_at
INTO OUTFILE '/tmp/users_export.csv'
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
FROM users
WHERE created_at >= '2024-01-01';

但这里有一个非常容易踩的坑：MySQL 出于安全考虑，限制了这个文件必须写在 secure_file_priv 指定的目录下。在 MySQL 8.0 中，这个变量默认是 NULL，表示完全禁止导出到文件。如果你执行上面的 SQL 报错：

code复制ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement

解决办法是修改 MySQL 配置文件：

ini复制[mysqld]
secure_file_priv = /tmp/mysql_export

修改后重启 MySQL。注意这个目录必须存在，而且 MySQL 进程要对它有写权限。

另外，导出的文件默认是 MySQL 服务端所在机器的路径，不是客户端的。很多人执行完 SQL 后在自己电脑上找不到文件，就是这个原因。

5.2 导出 CSV 后 NULL 值变成了字符串 "NULL"

这个细节很坑。SELECT INTO OUTFILE 导出时，NULL 值默认会被写成大写字符串 NULL，而不是空值。如果数据要导入数仓或做数据分析，NULL 会被当成一个普通字符串，语义完全错误。

解决办法是导出时用 IFNULL 函数手动处理：

sql复制SELECT IFNULL(id, ''), IFNULL(name, ''), IFNULL(created_at, '')
INTO OUTFILE '/tmp/users_export.csv'
FIELDS TERMINATED BY ','
OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
FROM users;

5.3 Sqoop 连接不上 MySQL 的常见原因

Sqoop 是 Hadoop 生态里最常见的 MySQL 数据导入工具。热搜词里“sqoop连接不上mysql”高频出现，我排查过不少次，原因基本集中在两类。

第一类是 JDBC 驱动问题。Sqoop 需要把 MySQL 的 JDBC 驱动 JAR 包放到 /opt/sqoop/lib/ 目录下，并且驱动类要写对：

bash复制sqoop import \
  --connect jdbc:mysql://192.168.1.10:3306/mydb \
  --username root \
  --password xxx \
  --table users \
  --target-dir /data/users \
  --driver com.mysql.cj.jdbc.Driver

注意 MySQL 8.0 之后的驱动类名是 com.mysql.cj.jdbc.Driver，旧驱动是 com.mysql.jdbc.Driver。用错驱动类，连接直接就挂了。

第二类是 认证插件不兼容。MySQL 8.0 默认的认证插件是 caching_sha2_password，而老版本的 Sqoop、JDBC 驱动、某些客户端（比如热搜里的 Firedac）默认只支持 mysql_native_password，于是就会报：

code复制Authentication plugin 'caching_sha2_password' cannot be loaded

或者类似 client does not support authentication protocol requested by server 的错误。

解决办法通常是在 MySQL 里把该账号认证插件改成旧的：

sql复制ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password';
FLUSH PRIVILEGES;

第二种方案是在 JDBC 连接串里加参数：

code复制jdbc:mysql://192.168.1.10:3306/mydb?allowPublicKeyRetrieval=true&useSSL=false

allowPublicKeyRetrieval=true 这个参数很关键，很多连接不上或连上后报错的情况都是因为它没开。

如果使用 MySQL 8.0+ 且不想改认证插件，也可以考虑下载 mysql-connector-java 最新版本，新版本已经兼容 caching_sha2_password。但生产环境里为了兼容各种老组件，我遇到过不少人直接选择把认证方式改回 mysql_native_password，简单粗暴，但要注意这会降低一定的安全性。具体怎么取舍，看你们的内部安全规范。

5.4 导出到报表平台时字段类型的雷

报表平台拿到数据后经常需要自动识别字段类型，但 MySQL 导出时默认会把一些类型写成“四不像”。

int 字段还好，本身就是数字。但 decimal(10,2) 导成 CSV 后，报表平台可能把它识别成字符串，因为带了小数点。datetime 字段变成 2024-06-01 12:30:00 后，有些平台会去掉中间的 T 导致解析失败。

我的经验是：如果同步到数仓或报表平台，尽量在导出 SQL 里就把格式标准化，比如：

sql复制SELECT
  id,
  CAST(amount AS DECIMAL(10,2)) AS amount,
  DATE_FORMAT(created_at, '%Y-%m-%d %H:%i:%s') AS created_time
FROM orders;

时间字段统一成 YYYY-MM-DD HH:mm:ss 格式，小数金额统一保留两位，这样下游处理时能少很多麻烦。

6. 导出前先看这几处：字段计算、排序与数据校验

导出数据不只是把表里的原样数据拿出去，很多时候你还得在导出前做一些处理。这里分享我在实际过程中经常用到、但教程里很少提到的三个细节。

6.1 导出时做线上计算：别在 SELECT 里偷偷改数据

有热搜词提到“mysql中int+5”，这通常是在开发环境里看到有人写 SELECT id+5 FROM users 这种语句。其实在真实导出场景中，也会有业务方在导出前要求对某些数值字段进行调整。比如“把所有人的薪资字段加 500 再导出”。

这里要明确一点：SELECT id+5 FROM users 只是查询返回结果时做了运算，并不会修改表里的原始数据。如果导出需求确实要调整字段值，可以在导出语句里做计算，但一定要跟业务确认清楚，导出的是调整后的数据，不是原表数据。否则下游拿到了数据，对不上账，你就要背锅了。

我习惯的做法是：任何带有计算、过滤的导出，都会在导出文件里加一列备注，或者在交付说明里写清楚“该字段已包含调整量”。

6.2 排序：导出顺序比你想的重要

默认情况下，SELECT * FROM table 的顺序是不保证的，尤其是没有主键或没有索引的表。如果你导出 CSV 给业务方，对方拿到数据后第一件事就是打开文件，发现顺序乱糟糟的，体验很差。

所以导出前养成一个习惯：总是指定 ORDER BY，哪怕只是按 id 排一下。这个操作不花时间，但能避免很多后续沟通成本。

6.3 导出前做行数校验

这一点是从我那个半夜导出翻车的同事身上学到的教训。他现在每次导出前都会做一步：用 COUNT(*) 查一下表总行数，导出完再数一下文件行数（CSV 减去表头行）。对不上就赶紧排查，别等交付了才发现数据少了一半。

bash复制# 导出前查行数
mysql -uroot -p -e "SELECT COUNT(*) FROM mydb.users;"

# 导出后数行数（假设有表头，减掉一行）
wc -l /tmp/users.csv

这个方法特别适合排查“导出的数据是不是被 DBeaver、Excel 这类工具截断了”的问题。

7. 日常导出报错速查：常见问题对照与处理建议

最后把我在工作中频繁遇到的导出相关报错汇总一下。这些错误单看都很简单，但组合起来，如果没有速查表，排查起来会非常耗时。

先说一个容易误解的地方：2059 错误不全出现在“导出”环节，常常在连接阶段就爆了。比如用旧版 Sqoop、老版本 JDBC 连接 MySQL 8.0 时，报 2059 的概率非常高。原因就是 8.0 默认认证插件改为 caching_sha2_password，老客户端不支持。解决办法在上面已经写过了，更新驱动优先，实在不行再改账号认证插件。

还有关于权限的报错。平时开发环境用的 root 账号权限足，所以很少遇到权限问题。但生产环境通常会给一个最小权限账号，导出时报 “Access denied” 的概率很大。这里建议给导出账号至少加上这些权限：

sql复制GRANT SELECT, LOCK TABLES, SHOW VIEW, TRIGGER, PROCESS ON mydb.* TO 'export_user'@'%';
FLUSH PRIVILEGES;

LOCK TABLES 是为了配合非 --single-transaction 的导出方式；PROCESS 权限在某些导出场景下也需要，但安全性上慎重一点，生产环境可以不给。

最后我还想多说一句：导出完的数据，最好自己先抽样打开看一遍，确认没有乱码、主键完整、行数吻合、日期格式符合预期，再发出去。因为数据一旦交给下游，出了问题再补，沟通成本和时间成本都很高。这个习惯救过我很多次，也希望这篇文章能让你少踩几个坑。