内容摘要：数据库导入数据这事儿，说穿了就三条路：文件导入、命令行灌入、程序代码逐条写。我见过太多人栽在第一步——拿个Excel就往生产库怼，结果字符集乱成一锅粥，或者主键冲突直接让导入进程崩掉。 文件导入最常用

数据库导入数据这事儿，数据数据说穿了就三条路：文件导入、库何命令行灌入、导入程序代码逐条写。数据数据我见过太多人栽在第一步——拿个Excel就往生产库怼，库何结果字符集乱成一锅粥，导入或者主键冲突直接让导入进程崩掉。数据数据

文件导入最常用，库何也最容易被忽视细节。导入CSV和Excel是数据数据主流，但Excel那玩意儿真不适合直接导。库何你永远猜不到它哪一列藏着换行符，导入哪一列日期格式变成了科学计数法。数据数据我的库何习惯是，先另存为CSV，导入再用文本编辑器打开检查一遍。别嫌麻烦，这一步能省下后面两小时的排错时间。具体到操作，MySQL的LOAD DATA INFILE、PostgreSQL的COPY命令，都是把文件路径和表结构对上就完事。但有个坑：CSV里的空值和NULL，你得提前想清楚怎么映射。空字符串和NULL在数据库里是两回事，查询结果天差地别。

命令行方式适合大数据量，几百万行起步那种。你写个INSERT语句一条条执行，那叫自虐。用mysql命令行工具，直接source一个.sql文件，或者用pg_restore恢复备份，效率完全不是一个量级。我记得有次帮朋友导一个1.2GB的备份文件，GUI工具卡到怀疑人生，切到命令行，加个--quick参数，十五分钟搞定。命令行看着吓人，其实就一条命令的事。但前提是你得搞清楚数据库的认证方式，密码别硬编码在脚本里，环境变量或者配置文件的权限设好，不然泄露了比导入失败还麻烦。

程序代码导入，适合业务逻辑复杂、需要清洗数据的场景。比如你从第三方API拉数据，或者老系统导出的数据格式乱七八糟。这时候写个Python脚本，用pandas或者SQLAlchemy，逐行处理再批量提交。批量提交别一次塞一万条，事务太大容易锁表，影响线上业务。我一般控制在500条一个批次，性能和数据安全平衡得刚好。写代码导数据有个好处——出错能重试，能打日志，能精确记录哪条数据有问题。坏处是，你得自己处理连接池、超时重连这些破事。

不管走哪条路，导入前必做三件事：备份目标表、检查目标表索引、评估数据量级。备份是保命符，万一导错了能回滚。索引这事儿反直觉——导入前把索引全删了，导完再重建，速度能快好几倍。因为每插一条数据，数据库都要更新索引树，索引越多越慢。数据量小无所谓，过了百万行，差距就明显了。

还有个经常被忽略的点：字符集。UTF-8和UTF8MB4在MySQL里不是一回事，前者存不了emoji。你导入的数据里要是藏着个表情符号，整批导入直接报错，前面的白干。所以我每次导数据前，先查一下源文件的编码格式，用file命令或者Notepad++看一眼，再跟数据库的character_set_database对比。不一致就先转换，别心存侥幸。

最后说个真实案例。上周帮客户导一份销售数据，CSV文件4.7万行，列名都正常，数据也干净。结果导进去之后，SUM汇总的金额对不上账。排查了半天，发现是某几行的金额字段带了千分位逗号，被数据库当成字符串存了。这种问题，文件肉眼看不出来，程序导入时加个类型转换就过了，但用文件导入就傻眼了。所以啊，导入前写个简单脚本扫一遍数据，类型不对的先挑出来，比啥都强。

说白了，数据库导数据就是个工程活儿，没什么高深的技术，全是细节和习惯。文件导入快但糙，命令行稳但冷，代码灵活但费时。你根据场景挑一个，把上面说的坑都避开，基本不会出大问题。要是真出了，也别慌，备份还在，重来一遍就是。