Excel数据导入MySQL避坑指南：CSV中转与批量导入实操

做数据的人基本都接到过这么个需求：对方发来一个Excel，说“帮我把这个塞进MySQL数据库，我要写SQL查”。新人第一反应往往是打开Navicat直接复制粘贴，几百行还能凑合，一旦里面混着日期、金额、电话号，粘贴完很快就会有人发现日期变成了奇怪的数字，长订单号后几位变成了0。

Excel文件要进MySQL，最省心的路其实不是反复复制粘贴，而是先导出成CSV，再用MySQL的导入机制批量读进去。今天这篇就把它讲透：包括前期为什么要多走这一步、Excel导出CSV时有哪些细节容易埋雷、MySQL导入CSV的几种可用姿势，以及我踩过的一些坑。

1. 为什么MySQL不直接吃Excel，偏偏认CSV

第一反应很容易是：为什么不能直接把xlsx文件导进去？用Navicat之类的图形工具，确实有直接导入Excel的入口，很多教程也这么写。但实际用下来你会发现，这条路听着近，走起来全是坑。

先从文件格式说起。xlsx不是普通的表格文本，它本质上是一个zip压缩包，里面塞了一堆XML文件来描述单元格、样式、公式、图表。这不是MySQL能直接解析的东西。图形客户端如果支持导入Excel，通常是在客户端本地装了解析Excel的组件后才能读，服务器上并没有这一套。所以一旦数据量大、格式复杂、字段类型不干净，工具的解析逻辑就容易自作主张，把你原来的值给“纠正”了。

CSV就完全不同。CSV是纯文本，一行一条记录，列与列之间用逗号隔开，没有任何格式、样式、公式的概念。它简单到用记事本都能打开，用任何编程语言都能读取，而且MySQL原生提供了LOAD DATA INFILE这种高性能导入指令，从设计上就是为了吃这种文件。

所以流程变成Excel转CSV再导入MySQL，不是绕路，而是走一条更稳的路。除了原始数据是Excel必须转格式外，如果你手上的数据本身就来自系统导出，那更是直接拿CSV往库里灌就行，连Excel都不用碰。

这个流程适合谁？适合所有需要把业务Excel表格变成数据库表的人：数据分析师、测试、运维、做报表的开发，以及经常需要处理同事丢过来的“Excel数据库”的倒霉蛋。无论你用的是Windows、macOS还是Linux，最终只要得到CSV文件，导入动作在服务器上都是同一套逻辑。

2. 导CSV之前，先给Excel表立规矩

很多人一上来就点“另存为CSV”，然后直接导入，接着开始处理各种报错。实际上，导入失败的原因有一大半在Excel这一侧就已经埋下了。

2.1 先建目标表，再回头检查Excel列

不要等CSV导出来才想“我该往哪张表里放”。正确的顺序是先设计好MySQL里的目标表，把字段名、字段类型定下来，再回头检查Excel里的列能不能对应上。

我一般会先写一段建表语句，类似于下面这样：

sql复制CREATE TABLE customer_order (
    id BIGINT PRIMARY KEY,
    customer_name VARCHAR(50),
    order_date DATETIME,
    region VARCHAR(30),
    amount DECIMAL(10,2)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有个容易被忽略的问题：Excel里的列名往往是中文，比如“客户姓名”“下单日期”，而数据库字段习惯用英文。我的建议是，尽量在Excel导出前就把表头改成和数据库字段对应的英文名，因为CSV文件第一行通常作为表头被忽略掉，但字段顺序需要对齐。如果实在不想改，那就导入时手工做映射，或者在导入后执行改名SQL。

2.2 合并单元格和数据格式是两大杀手

Excel里看起来很正常的数据，导入数据库时处处是雷。合并单元格是第一个坑：视觉上合并了两行的内容，实际上只有左上角那个格子有值，其他格子是空的。这种表导入数据库后，会出现大量关键列NULL的记录。

第二个坑是单元格格式。Excel里一个单元格显示“1000”，不代表它真的存的是1000，可能底层是带千位分隔符的文本，也可能隐藏着货币符号。导入到MySQL的DECIMAL字段时，这类字符就会导致Data truncated报错。

日期列尤其容易出问题。Excel中的日期本质上是一个从1900年开始计算的序列号，显示成“2024-01-17”只是穿了件外套。如果你的Excel列格式不统一，这一行显示“2024/1/5”，那一行显示“2024年1月5日”，CSV导出后就会是各种文本混杂，MySQL的DATETIME字段根本不认。

还有一类极其隐蔽的问题：订单号、身份证号、银行卡号这种超过15位的数字列。Excel的数值精度只有15位，超过部分会被强行改成科学计数法，第16位开始变成0。这块数据一旦导出成CSV，就已经坏了，后面怎么导入都没用。

我通常在让业务方发Excel之前，会先丢给他们一张要求清单：

• 第一行放字段名，行内不要有合并单元格
• 每列格式统一，金额列去掉货币符号和千分位符
• 日期格式统一写成 yyyy-mm-dd hh:mm:ss
• 身份证、订单号等长数字列，单元格格式设为文本
• 空值处留空，不要写“无”“/”“NA”这类五花八门的占位
• 清理掉单元格内多余的换行和首尾空格

这一套检查下来，后面至少能省下八成排查报错的时间。

2.3 表数据类型怎么对应

建表时字段类型的选择，比很多人想象的更重要。Excel没有数据类型的概念，所有格子本质都是文本，但MySQL有严格类型。对应关系可以参考：

核心原则是：凡是“看起来像数字但你不打算拿来做加减乘除”的列，一律按文本处理。身份证不是数字，是编号；订单号不是数字，是字符串；手机号也不是数字，别在MySQL里存成BIGINT，容易出各种诡异问题。

3. 另存为CSV：编码选择直接决定后面是否乱码

Excel导出CSV这一步，看起来就是“文件→另存为→选CSV”，但这里藏着全文最容易被忽略的坑：字符编码。

3.1 CSV(逗号分隔)和CSV UTF-8的区别

在Windows的中文环境下，旧版Office的“CSV(逗号分隔)”选项，默认按系统区域编码保存，也就是GBK或GB2312。这本身没什么问题，但MySQL数据库现在普遍使用utf8mb4字符集。文件里的中文是GBK，MySQL却按UTF-8去解读，导入后必然出现乱码，或者直接报1366错误。

新版Excel通常提供了两个选项：“CSV UTF-8(逗号分隔)”和“CSV(逗号分隔)”。绝大多数场景下，都建议选前面的CSV UTF-8。

如果你在公司环境用的是老版Excel，或者只有WPS，没有UTF-8选项，那也没关系。文件导出来后先用工具转换一下编码：

bash复制iconv -f GBK -t UTF-8 original.csv > converted.csv

转换完后再用文本编辑器确认一下内容是否正常。macOS版Excel另存为CSV时一般默认就是UTF-8，但也要打开确认。

有人可能会问，能不能不转码，直接在LOAD DATA时声明文件编码是GBK？也可以。导入命令里写CHARACTER SET gbk就行，MySQL会负责把文件编码转换成目标表字符集。但这要求你心里门儿清文件到底是什么编码，一旦猜错，报错比乱码还难排查。所以我的习惯是，一步到位把文件转成UTF-8，后面少一桩心事。

3.2 别用Excel二次打开CSV文件

这是我最想强调的坑：CSV导出后，不要又用Excel打开去看，更不要在里面改了之后再保存一遍。

Excel打开CSV时，会按照自己的规则重新解析内容。它可能会把“00123”变成“123”，把“2024-01-17”变成日期序列号，把超过15位的数字变成科学计数法。你以为只是“看一下”，实际上文件内容已经被破坏了。等你保存后，前面做的所有清理工作全部白费。

检查CSV的正确方式是：用记事本、VS Code、Notepad++之类的纯文本编辑器打开，或者在命令行直接看前几行：

bash复制head -n 5 file.csv

这样看到的才是文件的真实状态。如果只是要快速确认行数和大小，也可以用：

bash复制wc -l file.csv

3.3 BOM标记带来的第一列乱码

Windows下另存的CSV UTF-8，经常会在文件开头带一个BOM标记，就是几个不可见字节，用来告诉编辑器“我是UTF-8编码”。MySQL对BOM的处理不一定友好，有时候导入后发现第一列列名前面多了几个乱码字符，其实就是BOM在作怪。

处理也简单，去掉BOM再导：

bash复制sed -i '1s/^\xEF\xBB\xBF//' file.csv

或者用VS Code打开文件，右下角把编码从“UTF-8 with BOM”改成“UTF-8”，重新保存一遍。

4. 导入MySQL的三条路线，按场景选而不是按习惯选

拿到干净的CSV文件后，就到了导入环节。我分别介绍一下图形向导、LOAD DATA命令和临时表转换这三条路线，以及各自适合什么场景。

4.1 Navicat导入向导：适合一次性小批量

如果你用的是Navicat，而且文件只有几千上万行，用自带导入向导是最快的。操作步骤是：

1. 在左侧找到目标表，右键选择“导入向导”
2. 文件类型选择CSV，点击下一步
3. 选择CSV文件路径
4. 编码选择UTF-8，也就是65001
5. 勾选“首行包含字段名”
6. 确认源字段和目标字段的映射关系
7. 执行导入

这套流程最大的好处是直观，字段映射能在图形界面上一一对应。但它有两个明显的短板：第一，数据量达到几十万行时，图形向导的速度明显变慢，有时还会出现内存占用过高的情况；第二，整个过程没法脚本化，每次都要手工点一遍，不适合重复性的定时导入任务。

所以我的定位是：临时用一次、数据量小、不追求自动化时，用Navicat没问题。真正上生产或需要反复导入的场景，建议用下面的LOAD DATA。

4.2 LOAD DATA INFILE：主力方案

命令行下的LOAD DATA是MySQL导入CSV的主力，性能远高于逐条INSERT。下面是一段最常用的导入语句：

sql复制LOAD DATA LOCAL INFILE '/home/user/customer_order.csv'
INTO TABLE customer_order
CHARACTER SET utf8mb4
FIELDS TERMINATED BY ','
OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(id, customer_name, order_date, region, amount);

先把参数逐个说清楚：

• LOCAL：表示文件在客户端机器上，MySQL客户端会把文件内容传到服务器执行。如果不加LOCAL，那就要求文件放在MySQL服务器本地，并且受secure_file_priv参数限制。
• CHARACTER SET utf8mb4：这里声明的是CSV文件的编码，而不是目标表编码。MySQL会按照这个声明识别文件，再自动完成到目标表字符集的转换。
• FIELDS TERMINATED BY ','：列分隔符是逗号，也说清了为什么叫CSV（Comma-Separated Values）。
• OPTIONALLY ENCLOSED BY '"'：当某个字段内容里含有逗号或者换行时，CSV规范会用双引号把整个字段包起来。这个参数就是告诉MySQL：遇到双引号包裹的内容，把它当成一个完整字段，别把里面的逗号当分隔符。
• LINES TERMINATED BY '\n'：行结束符。Windows上导出的文件通常是\r\n，如果按\n切分行，行尾可能会带着一个\r混进最后一列。这种情况把行结束符换成'\r\n'即可。
• IGNORE 1 LINES：表示跳过第一行，因为第一行是列名。

执行LOAD DATA前，先检查一个MySQL服务端参数：

sql复制SHOW VARIABLES LIKE 'secure_file_priv';

这个参数有几种情况：

如果该值显示为NULL，你又希望走服务端文件路径，那就得修改MySQL配置文件my.cnf或my.ini，增加一行：

ini复制secure-file-priv=""

然后重启MySQL服务。

如果不想折腾配置文件，就直接用LOCAL方式。但要注意，MySQL 8.0客户端默认可能没开启local-infile，连接时需要显式加上：

bash复制mysql --local-infile=1 -h你的IP -u用户名 -p数据库名

执行完LOAD DATA后，正常会看到类似“Records: 120000 Deleted: 0 Skipped: 0 Warnings: 0”的输出，其中Records是读取的总行数，Warnings是导入过程中的警告数。如果Warnings不是0，千万别忽略，哪怕最后数据进去了，也可能存在类型转换或截断问题。

4.3 字段需要转换时，先导临时表

LOAD DATA虽然快，但它默认是“原样放进字段”，遇到格式不那么规整的数据就会报错或放空。比如Excel里的日期是“2024/01/05”，或者金额列里带逗号“1,200.00”，直接往DATE/DECIMAL字段里塞，MySQL并不领情。

我的做法是，遇到这类情况时，先建一张所有列都用VARCHAR或TEXT的临时表，把CSV原样倒进去，然后再用INSERT...SELECT把数据清洗后转入正式表。

sql复制CREATE TABLE tmp_customer_order (
    id VARCHAR(32),
    customer_name VARCHAR(255),
    order_date VARCHAR(32),
    region VARCHAR(255),
    amount VARCHAR(32)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

CSV先倒入这张临时表，然后转换：

sql复制INSERT INTO customer_order (id, customer_name, order_date, region, amount)
SELECT
    CAST(id AS UNSIGNED),
    customer_name,
    STR_TO_DATE(order_date, '%Y/%m/%d'),
    region,
    CAST(REPLACE(amount, ',', '') AS DECIMAL(10,2))
FROM tmp_customer_order;

这么做有几个好处：清洗逻辑单独写在SQL里，能反复执行、容易排查；正式表不会因为导入格式问题被半路卡住；遇到脏数据，报错信息也会指向具体的转换SQL，而不是笼统的一堆Warnings。

5. 导入后的数据校验与高频故障排查

导入成功不等于万事大吉。我发现不少人LOAD DATA执行完，看到Records没有报错就走了，结果第二天业务方说数据对不上。导入后校验和数据清洗同样重要。

5.1 导入完先跑这几条SQL

最基础的校验是行数和关键字段的空值检查。

sql复制-- 查看总行数
SELECT COUNT(*) FROM customer_order;

-- 查看关键字段是否有空值
SELECT COUNT(*) FROM customer_order WHERE id IS NULL OR id = '';

-- 查看是否有明显异常日期的行
SELECT * FROM customer_order WHERE order_date < '2000-01-01' OR order_date > NOW();

-- 抽样查看导入后的真实内容
SELECT * FROM customer_order ORDER BY id LIMIT 20;

还有一种校验在实际业务中更实用：回到源头，对比Excel或CSV文件行数与数据库行数。Excel最下方状态栏会显示总行数，CSV文件可以用wc -l统计，两边数字一致是对账的第一步。

如果导入的表有唯一键，还可以用分组查询看有没有重复：

sql复制SELECT id, COUNT(*) 
FROM customer_order 
GROUP BY id 
HAVING COUNT(*) > 1;

5.2 高频报错对照表

下面这些是我在实际操作中遇到次数最多的问题，整理成表供快速排查。

5.3 两个真实故障的复盘过程

说两个我自己栽过的跟头，更能还原这类问题的排查思路。

第一个是乱码问题。当时收到一个CSV文件，直接用LOAD DATA导入，命令里写了CHARACTER SET utf8mb4，结果报出大量1366错误。我第一反应是“文件坏了”，但用文本编辑器打开文件，中文明明正常。

后来静下来想了想，Windows下老版Excel导出的CSV不带UTF-8选项，默认是GBK。我在LOAD DATA里声明它是UTF-8，MySQL按UTF-8解码GBK内容，自然解出非法字符。解决方案有两种：要么把命令改成CHARACTER SET gbk，要么用iconv转成UTF-8再导。我选择了后者，因为后续所有环节都统一用UTF-8，免得哪天又要排查。

第二个是日期问题。业务方给的表里有一列“下单时间”，看起来都是“2024-01-17 10:23:45”，但导入后大量行变成0000-00-00。检查CSV原文才发现，有些单元格里存的是“2024/01/17”，Excel显示时自动格式化成统一样子了，但CSV导出时暴露了各自的真实形状。遇到这种情况不能用LOAD DATA硬刚，走一遍临时表，用STR_TO_DATE做了规整，再转进正式表。

这里有一个很重要的排查思路：出问题别急着改MySQL配置，先把CSV文件用纯文本编辑器打开，看看里面对应的那一行数据到底是什么形状。很多时候数据在文件层面就已经不如你想的那么干净了。LOAD DATA只是忠实执行者，真正的问题往往在文件源头。

6. 导入变成例行任务后，怎么把这套流程固定下来

如果你只需要处理一次，读到上面就够了。但我猜有相当一部分人面临的情况是——每周、每月都要把业务方发来的Excel导入MySQL。这种重复劳动不走自动化，就是在内耗。

6.1 约定文件规范，省去每次沟通成本

第一次和业务方合作时，就把Excel的格式规范提出来：第一行必须是表头、日期统一格式、金额列不带货币符号、不要合并单元格。同时约定好文件名规则，比如customer_order_20250120.csv，带日期后缀。文件命名规整的好处是，脚本覆盖旧文件时方便归档，排查问题也知道是哪天的数据。

6.2 把LOAD DATA封装成脚本

Linux环境下，我习惯把导入流程写成一个shell脚本，里面干几件事：检查文件是否存在、备份旧文件、执行LOAD DATA、校验行数。

bash复制#!/bin/bash
CSV_FILE="/data/import/customer_order_$(date +%Y%m%d).csv"
TABLE_NAME="customer_order"

if [ ! -f "$CSV_FILE" ]; then
    echo "CSV文件不存在: $CSV_FILE"
    exit 1
fi

mysql --local-infile=1 --default-character-set=utf8mb4 -u导入用户 -p数据库密码 数据库名 <<EOF
LOAD DATA LOCAL INFILE '$CSV_FILE'
INTO TABLE $TABLE_NAME
CHARACTER SET utf8mb4
FIELDS TERMINATED BY ','
OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(id, customer_name, order_date, region, amount);
SELECT ROW_COUNT() AS imported_rows;
EOF

当然，密码直接写在命令行里并不优雅，生产环境更推荐用~/.my.cnf配置账号信息，或者通过环境变量读取。核心思路是：把每次手工操作变成一条命令，降低重复操作出错的机会。

如果是Windows环境，同样的逻辑可以写成批处理文件，或者用计划任务调用一个Python脚本。Excel本身也能挂VBA宏来自动完成另存为CSV的动作，如果你能说服业务方在发数据前用宏一键输出CSV，那Excel原始文件都可以不进你服务器。

6.3 重复导入同一张表，如何避免脏数据和重复数据

如果每次导入都是全量覆盖，最笨但也最稳妥的方式是：导入前先TRUNCATE或DELETE清掉旧数据，再导入新文件。但如果业务方只发增量数据，或者你只想更新新增和变化的行，那就需要兜底的去重方案。

我常用的套路是双表方案：先把CSV导入一张临时表，再用一次INSERT...ON DUPLICATE KEY UPDATE把临时表的数据合并进正式表。这样即使CSV里有重复主键，也不会导致导入失败，只会按设定更新字段。

SQL大致长这样：

sql复制INSERT INTO customer_order (id, customer_name, order_date, region, amount)
SELECT id, customer_name, order_date, region, amount
FROM tmp_customer_order
ON DUPLICATE KEY UPDATE
customer_name = VALUES(customer_name),
order_date = VALUES(order_date),
region = VALUES(region),
amount = VALUES(amount);

这套做法牺牲了一点性能，但换来了幂等性——同样的文件导入两次，结果不会翻倍。对“业务方每周发一份全量Excel”这种场景，这是一条相当实用的兜底方案。

6.4 关于大文件的最后提醒

Excel单个工作表最多能撑到1048576行，超过这个数量级的文件，Excel本身就装不下了。所以如果你的数据量已经奔着几百万行去，就别在Excel里周转了，直接让业务方从源系统导出CSV给你。LOAD DATA对这种文本文件的导入速度比你想象中快得多，几十万行也就几秒到几十秒的事，真正的瓶颈永远在源头文件的格式和清洗。

另外，大文件导入时，尽量把MySQL的事务隔离级别和会话设置