把一份 Excel 表格塞进 SQL 数据库，导入听起来像把大象装进冰箱——打开、据库放进去、导入关上。据库真干起来，导入十次有八次会卡在某个字段上。据库上周同事发来一份销售记录，导入三万行，据库五列，导入看着挺干净。据库导入 SQL Server 时，导入日期列全变成了 1900-01-01。据库原因？导入Excel 里那列混了文本格式的“2024/3/5”和真正的日期序列值。数据库不认，据库直接给你个默认值。导入

这种坑踩多了，就明白一件事：Excel 导入 SQL，关键不在“导”，在“洗”。数据清洗占八成时间，剩下两成才是敲命令。我习惯先把 Excel 另存为 CSV，再用数据库的批量导入工具。别直接用 SSMS 的“导入向导”选 Excel 文件——它背后走的是 ACE 驱动，32 位和 64 位版本一打架，报错能让你怀疑人生。CSV 没这毛病，纯文本，谁都能读。

拿 MySQL 举例。建表时字段类型要和 CSV 内容对得上。比如手机号，Excel 里是数字，但前头有零，存成 INT 就丢了。得用 VARCHAR(15)。日期字段更麻烦，CSV 里可能是“2024-03-05”或“05/03/2024”，MySQL 的 STR_TO_DATE 函数能救场。我一般先建个临时表，所有字段设为 VARCHAR，导完再写 INSERT INTO ... SELECT 做转换。这样出错能定位到具体行，不用重导整个文件。

LOAD DATA LOCAL INFILE '/path/sales.csv' INTO TABLE temp_sales FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n' IGNORE 1 ROWS;

这行命令跑完，三万行通常几秒就进去了。但有个细节：CSV 里的换行符。Windows 默认 \r\n，Linux 是 \n。如果文件在 Windows 编辑过，LINES TERMINATED BY 要改成 '\r\n'，否则最后一行可能带个隐藏的 \r，导致数字字段报错。这个坑我吃过两次，现在每次导入前都用 Notepad++ 的“显示所有字符”看一眼。

SQL Server 用户可以用 BULK INSERT，速度比图形界面快一个量级。但记得开 xp_cmdshell 或者用 SQLCMD 模式。有个客户坚持用导入向导，五万行跑了二十分钟，中间还断了。换成 BULK INSERT 后，四秒。他问我为什么，我说向导每行都在做类型推断，BULK INSERT 直接按你定义的表结构灌，当然快。

导入完成不代表结束。检查行数：SELECT COUNT(*) 和 Excel 的 COUNTA 对一下。再看关键字段有没有 NULL，尤其是主键。有一次导完发现订单号少了 47 条，查半天是 CSV 里有个字段值包含逗号，被错误分割了。解决办法是用双引号包裹所有文本字段，或者换用制表符分隔。Excel 另存为“文本（制表符分隔）”就能避开逗号问题。

最后说个野路子。如果数据量不大，几千行，直接复制 Excel 区域，在数据库客户端里粘贴到表上，很多工具支持。Navicat、DBeaver 都行。但字段顺序必须完全一致，且不能有公式。我试过粘贴带 VLOOKUP 的列，结果进去全是 #REF!。所以粘贴前先“选择性粘贴 - 值”。这招适合临时补数据，正式迁移还是走 CSV 稳。

导入完记得跑一遍 SELECT TOP 100 看看。数据这东西，眼睛过一遍比什么校验都管用。有次导完发现金额列全变成了科学计数法，1.23E+05。回头查 CSV，原来那列在 Excel 里被设成了“常规”格式，大数自动转科学计数。重新设成“数值”再导出，解决了。所以别信 Excel 的默认格式，它总在你不注意的时候动手脚。

(责任编辑：百科)