LOAD DATA INFILE 是唯一能真正扛住千万级导入的方案，因其绕过SQL解析、权限校验和网络往返，直接由服务端批量写入存储引擎；而批量INSERT受限于max_allowed_packet、锁持有时间、索引实时校验及隐性数据类型转换，难以稳定支撑千万级高效导入。
LOAD DATA INFILE 是唯一能真正扛住千万级导入的方案，其他方式都只是“能用”，不是“够快”。
为什么 INSERT VALUES 批量插入撑不住千万级？
它看着简单，但每批超过 8000 行就容易触发隐性瓶颈：
• max_allowed_packet 默认常为 4MB，含中文或长文本时，5000 行就可能超限，报错 Packets larger than max_allowed_packet are not allowed；
• 单条大语句在 InnoDB 可重复读下会持锁更久，容易阻塞其他写操作；
• 带 ON DUPLICATE KEY UPDATE 或 REPLACE 会强制索引查找，速度下降 30% 以上；
• 没有预校验机制，字段类型不匹配（比如 CSV 里空字符串往 INT 字段插）会静默转成 0 或报 Incorrect integer value，数据就歪了。
LOAD DATA INFILE 必须满足的三个硬条件
跳过任一条件，命令直接失败或行为不可控：
• 查 secure_file_priv 路径：SHOW VARIABLES LIKE 'secure_file_priv';，文件必须放在该目录下（如 /var/lib/mysql-files/），不能用相对路径或软链；
• 当前用户要有 FILE 权限：GRANT FILE ON *.* TO 'user'@'host';，仅 SELECT 或 INSERT 权限不够；
• 表必须已存在，且字段顺序、类型、NULL 属性要和 CSV 完全一致——比如表定义是 created_at DATETIME NOT NULL，CSV 对应列就不能是空或非法日期字符串。
导入前必须关的不是 DISABLE KEYS，而是这两个 SET
ALTER TABLE t DISABLE KEYS 对 InnoDB 完全无效，这是 MyISAM 的老套路，误用只会白忙：
• 正确做法是导入前执行：SET unique_checks=0; 和 SET foreign_key_checks=0;；
• unique_checks=0 期间不校验唯一约束，如果源数据本身含重复主键，后续设回 1 会触发全表扫描并报错，必须提前去重；
• foreign_key_checks=0 不跳过外键索引更新，所以关联字段仍需有索引，否则导入后重建索引（SET unique_checks=1 触发）会卡死；
• 导入完成后，务必按顺序恢复：SET unique_checks=1; → 等它校验完 → 再 SET foreign_key_checks=1;。
字符集、空值和字段映射的实操细节
这些地方不处理，中文乱码、\N 被当字符串、时间格式错位全是常态：
• 文件必须存为 UTF-8 无 BOM 编码，建表时指定 CHARSET=utf8mb4；
• 导入前加 SET NAMES utf8mb4;，否则客户端和服务端编码不一致；
• CSV 中 NULL 值写成 \N（不是空字符串），并在语句中显式声明：SET col = NULLIF(@col, '')；
• 字段顺序不匹配？用 SET 子句映射：SET created_at = STR_TO_DATE(@date_str, '%Y/%m/%d %H:%i')；
• 需跳过首行标题？加 IGNORE 1 ROWS，但注意它只跳物理行，不校验逻辑结构。
真正难的不是写对那条 LOAD DATA INFILE 语句，而是确保 CSV 文件从生成那一刻起，就和目标表的字段定义、字符集、空值约定严丝合缝——任何环节松动，都会在千万行后某个凌晨三点爆出一个你没准备好的错误。
