MySQL LOAD DATA 导入大文件怎么升级：字符集、错误行处理与原子切换

线上一次性导入几百万行 CSV，真正容易出问题的通常不是命令能不能跑，而是跑完后没人能回答“哪些行没进来、字符集有没有串、失败时怎么退回去”。把 LOAD DATA 放进临时表、显式声明字符集，并把警告和业务校验分开，导入才有可复查、可回滚的边界。

先把大文件导入拆成三个验收阶段

处理大文件导入时不用一上来就直接往线上业务表写入，把整个流程拆成「解析、落地、切换」三段就很顺畅。解析阶段重点适配分隔符、引号、换行规则和字符集；落地阶段重点对齐列类型、校验唯一键和捕获错误行；切换阶段才触碰线上表。任何一段执行失败，都不会在业务库留下半份脏数据。

升级导入命令：先固定字符集和字段边界

不要直接把当前连接的默认字符集当成待导入文件的实际编码。假设外部交付的文件是 UTF-8 编码、字段以逗号分隔、文本内容用双引号包裹，命令可以先按照这个规则调试写成下面这样：

LOAD DATA LOCAL INFILE '/data/orders-20260824.csv'
INTO TABLE orders_stage
CHARACTER SET utf8mb4
FIELDS TERMINATED BY ','
       OPTIONALLY ENCLOSED BY '"'
       ESCAPED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(external_id, customer_name, amount_text, created_at_text);

这里使用文本列接收金额和时间，是为了先看原始值。直接把 amount_text 映射到 DECIMAL，遇到空字符串、千分位或尾部空格时，数据库可能给出警告，但批处理仍然继续，问题反而更难定位。

Windows 换行和 BOM 要单独验收

如果文件来自 Windows，行尾可能是 \r\n。导入后发现最后一列多出回车，先检查文件本身与文本编辑器的编码提示，再决定是否把行尾写成 LINES TERMINATED BY '\r\n'。不要为了“让它跑完”盲目改 SQL，命令与文件约定必须一起记录。

错误行怎么留下证据，而不是只看客户端提示

IGNORE 只能改变重复键或部分错误的处理策略，不能代替错误审计。导入后先看客户端返回的 affected rows 与 warnings，再把 staging 中无法转换的字段筛出来：

SELECT external_id, amount_text, created_at_text
FROM orders_stage
WHERE amount_text = ''
   OR amount_text NOT REGEXP '^-?[0-9]+(\\.[0-9]+)?$'
   OR STR_TO_DATE(created_at_text, '%Y-%m-%d %H:%i:%s') IS NULL;

错误记录可以复制到 orders_import_errors，附上 run_id、原始行号和错误原因。这样下次补传时，补的是明确的一小批，而不是重新猜整个文件。

用临时表完成可回滚的原子切换

如果目标表名是 orders，先准备结构相同的 orders_stage，补齐必要索引，再做三类检查：行数与源文件记录数对得上，业务主键没有重复，金额和时间字段都能转换。检查通过后，在低流量窗口执行短事务切换：

RENAME TABLE orders TO orders_backup_20260824,
             orders_stage TO orders;

RENAME TABLE 的优点是切换动作短，失败时可以把新表名换回去。旧表不要立即删除，至少保留到抽样查询、下游任务和报表都完成一轮验证。若表上有外键、触发器或依赖固定表名的权限配置，切换前先在预生产环境演练，这些依赖不会因为导入成功自动消失。

版本迁移时最容易漏掉的回归检查

• 同一文件在目标 MySQL 版本上导入，字符集与排序规则是否仍一致。
• 启用严格 SQL 模式后，原先的警告是否变成错误，错误表是否能接住。
• 客户端使用 LOCAL 时，服务端与驱动的本地文件开关是否按安全策略开启。
• 失败重跑是否会产生重复业务键，或把上一次 staging 残留混入本次批次。

常见问题：导入成功不等于数据可用

为什么 affected rows 正常，但仍有脏数据？

LOAD DATA 可以在出现警告时继续处理。应把 warnings 收集、字段格式抽样校验和业务总量核对放在成功判定逻辑里，不能只看命令退出状态就认为导入完全正常。

大文件应该直接导入线上表吗？

除非表本身就是可重建的离线测试表，否则不建议直接往线上业务表跑LOAD DATA。staging 表能把解析错误、唯一键冲突和业务校验完全隔离开，也给后续回滚留下充足操作空间。

导入中断后怎么重跑？

为每次导入作业生成唯一 run_id，清理或重建对应批次的 staging 表后再重跑；不要直接对半成品执行增量补导，除非文件有稳定的外部主键和明确的幂等校验规则。

把一次命令变成可审计的迁移清单

整个流程做完的最终交付物至少应包括文件编码和换行约定、完整可复用的 LOAD DATA 命令、源文件行数、staging 校验结果、错误行清单、切换时间点和应急回滚命令。这样下一次换驱动、换服务器或升级 MySQL 时，迁移检查的都是实打实的记录，不是某个人记忆里的“上次就是这么导的”。