excel表格导入数据库

把Excel表格往数据库里导，格导最省事的入数办法往往不是最稳妥的。我见过太多人直接复制粘贴，据库结果日期变成一串数字，格导手机号前面多了个撇号，入数金额小数点后两位莫名其妙消失。据库问题不在Excel，格导也不在数据库，入数出在中间那层“想当然”的据库转换逻辑上。

上周帮一个做电商的格导朋友处理订单表。他导了三次，入数三次都报错。据库第一次是格导订单号里的字母被截断，因为数据库字段设成了INT。入数第二次是据库收货地址里的换行符把一行数据劈成了两行。第三次更离谱，Excel里看着是“2024-03-15”，导进去变成了“2024-03-15 00:00:00”，多出来的时间戳让后续查询全乱套。他拍着桌子说Excel有毒，其实是他没搞明白：Excel单元格的“格式”和“值”是两码事。

数据库不认格式，只认值。你在Excel里把一列设成“文本”，看着是“001”，但底层存的还是数字1。导进去自然变成1。反过来，日期在Excel里是浮点数，1900年1月1日是1，2024年3月15日是45366。数据库的DATE类型可不吃这套。所以导之前，先把Excel里那些“看起来对”的列，用TEXT函数或者分列功能转成真正的文本或标准日期格式。

字段类型对不上只是第一关。空值处理更隐蔽。Excel里空单元格导进数据库，有的工具给NULL，有的给空字符串。差别大了。NULL不占索引空间，空字符串占。如果那个字段有唯一约束，两个空字符串直接冲突。我习惯在导之前，把Excel里所有空单元格批量填上“\N”或者特定占位符，导完再用SQL统一更新成NULL。多一步，少一堆麻烦。

编码问题也常被忽略。Excel默认存成GBK，数据库要是UTF-8，中文名里的生僻字直接变问号。有个做古籍数字化的客户，导“龘”字导了七次，每次都是乱码。后来用Notepad++把CSV转成UTF-8无BOM格式，一次通过。BOM头也得注意，有些数据库驱动会把BOM当成字段内容的一部分，第一个字段名前面多个不可见字符，建表就失败。

工具选择上，别迷信图形界面。Navicat的导入向导很友好，但遇到大文件容易卡死。超过50万行，直接用LOAD DATA INFILE或者Python的pandas.to_sql。pandas的好处是能逐块读取，内存不够就设chunksize。我试过用pandas导一个120万行的销售表，每块5万行，边读边写，二十分钟跑完，中间还能看到进度条。图形界面这时候只会转圈。

最后说个反直觉的：导之前先建好索引，反而更慢。正确做法是先把表结构建好，但不加索引，导完数据再ALTER TABLE ADD INDEX。批量插入时，每插一行都更新索引，开销翻倍。我做过对比，同样100万行数据，先建索引比后建索引多花三倍时间。这个细节，很多教程不提。

导数据这事，说到底是跟“默认行为”较劲。Excel的默认、数据库的默认、工具的默认，三方默认凑一起，不出错才怪。每次导之前，拿十行数据做样本，手动核对一遍字段类型、空值、编码、日期格式。十分钟的检查，省三小时的排查。别问我怎么知道的。