用 LOAD DATA IGNORE 导入时识别违反 CHECK 的行并保留警告信息

我在批量导入时最不愿意看到的一种“成功”，是命令正常结束，却没有人知道哪些行被约束挡住了。对于 MySQL 的 CHECK 约束，比较稳妥的做法是把导入和诊断拆成一个紧凑的会话动作：使用 LOAD DATA ... IGNORE 让合法行继续进入表，紧接着执行 SHOW COUNT(*) WARNINGS 和 SHOW WARNINGS，再把明细交给审计或失败行处理流程。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/create-table-check-constraints.html

关键点只有一个：IGNORE 会把 CHECK 判定为 FALSE 的行跳过并产生警告，但警告属于当前会话最近一条语句的诊断信息，必须在下一条普通查询之前读取。

生产目标：只跳过违反 CHECK 的行

MySQL 会在 INSERT、UPDATE、REPLACE、LOAD DATA 和 LOAD XML 等语句中评估 CHECK。约束表达式返回 TRUE 或 UNKNOWN 时，行可以通过；返回 FALSE 时就是约束违规。

不带 IGNORE 时，违规会按普通错误处理；加上 LOAD DATA ... IGNORE 后，MySQL 会对 CHECK 违规产生警告，并跳过对应行继续导入。这个语义正好对应“合法数据先落表、问题数据留痕”的批量任务，但它不等于忽略所有错误，也不等于自动生成一张失败行表。

环境准备：让 CHECK 只承担业务边界

为了让导入后的警告有明确含义，先把约束写成一个简单、可解释的业务条件。下面的例子只关心金额不能为负，不讨论 CSV 的引号、换行或字段类型解析。

CREATE TABLE import_order (
    order_no BIGINT NOT NULL PRIMARY KEY,
    amount DECIMAL(12, 2) NOT NULL,
    CONSTRAINT chk_import_order_amount CHECK (amount >= 0)
);

-- 这个约束只负责判断金额边界，导入格式仍由 LOAD DATA 的字段配置负责。
-- 约束名称固定后，后续警告和审计记录更容易按规则归类。

这里把约束命名为 chk_import_order_amount，是为了让人工排查时知道它属于哪个业务边界。生产表中可以有多个 CHECK，但每个约束最好只表达一个容易解释的条件。这样即使一行同时触发多个规则，审计人员也能根据消息定位到约束方向。

安全配置：用 LOAD DATA IGNORE 保留可用行

导入语句的重点是 IGNORE 放在 INTO TABLE 之前，并且让后续诊断仍然使用同一个 MySQL 连接。下面示例假设文件首行为表头，列顺序已经和目标表一致；字段解析不是本文重点。

LOAD DATA LOCAL INFILE '/data/incoming/orders.csv'
IGNORE INTO TABLE import_order
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(order_no, amount);

-- IGNORE 让 CHECK 失败的行跳过，后续合法行仍有机会继续写入。
-- LOCAL 文件能力还受客户端和服务端配置影响，生产环境要按组织的文件权限策略开启。

如果批次中有一行金额为负数，它不会因为 IGNORE 而被改成零，也不会自动写入一张“拒绝表”；它会被跳过，并在当前会话的诊断信息里留下警告。这个区别很重要：业务若要求逐行回放，就必须在客户端读取警告后自行保存原始批次标识或失败行。

权限边界：导入账号只拿完成任务所需的能力

批量导入常被当成一次性的运维动作，但 LOAD DATA LOCAL INFILE 涉及客户端读取本地文件，账号和客户端能力都应按最小范围配置。文章这里不展开授权语句，而是给发布前的三个边界：

• 使用专用导入账号，只授予目标库表的导入和读取诊断所需权限，不把日常应用账号拿来跑批。
• 限制可读的文件目录，避免把任意本地路径当作导入源。
• 把批次编号放在应用层或客户端日志里，不能只依赖终端上的一行“Query OK”。

这些是运行边界，不会改变 CHECK 的判断结果。它们的价值在于：当警告需要被追溯时，能够回答“哪个批次、哪个连接、哪个文件、哪个导入账号”执行了这次导入。

日志审计：紧接着读取 SHOW COUNT 与 SHOW WARNINGS

SHOW WARNINGS 展示的是当前会话最近一条非诊断语句产生的错误、警告和提示；SHOW COUNT(*) WARNINGS 给出总数。导入成功返回并不表示警告为空，所以我会把两条诊断语句紧贴在 LOAD DATA 后面。

-- 这三条语句必须保持在同一个客户端连接中连续执行。
LOAD DATA LOCAL INFILE '/data/incoming/orders.csv'
IGNORE INTO TABLE import_order
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(order_no, amount);

-- 先拿总数，再拿明细；SHOW COUNT(*) WARNINGS 不会清掉诊断列表。
SHOW COUNT(*) WARNINGS;
SHOW WARNINGS LIMIT 100;

输出可以按下面的形式理解，具体级别、错误码和消息应以本次连接真正返回的内容为准：

+----------+
| @@warning_count |
+----------+
|          2 |
+----------+

+---------+------+----------------------------------------------+
| Level   | Code | Message                                      |
+---------+------+----------------------------------------------+
| Warning | ...  | Check constraint 'chk_import_order_amount' is violated |
| Warning | ...  | Check constraint 'chk_import_order_amount' is violated |
+---------+------+----------------------------------------------+

不要在导入后先执行 SELECT 再回来查看警告。MySQL 文档说明，普通的非诊断语句会改变“最近一条语句”的诊断上下文；例如直接执行 SELECT @@warning_count 会清理消息列表。若只是想查看计数，优先使用 SHOW COUNT(*) WARNINGS，然后立即获取明细。

日志审计：把警告交给客户端持久化

MySQL 的警告列表适合即时诊断，不适合作为长期审计存储。真正要“保留”信息时，客户端应在同一连接读取 SHOW WARNINGS 的结果，并为每一行附加批次号、文件名、导入时间和目标表，再写入单独的审计表或日志系统。

# 用 mysql 客户端把导入和诊断放在一次会话中；输出文件交给审计流程保存。
mysql --local-infile=1 --batch --raw app_db 

如果审计要求结构化字段，不要依赖终端文本的排版。使用数据库驱动读取警告结果集，把 Level、Code、Message 与批次元数据写入审计表；同时保留源文件的不可变标识。这样才能在后续重新处理时区分“同一行再次失败”和“另一批次产生相同消息”。

发布检查：区分总数、明细和存储上限

生产发布前，我会把下面几项列入检查单：

max_error_count 控制服务器最多保存多少条错误、警告和提示消息，但不限制实际统计到的总数。也就是说，警告总数可能大于 SHOW WARNINGS 能展示的明细数。批次很大时，应提前设置合理的存储上限，或者让客户端在更小批次中读取并保存明细。

几个容易踩坑的边界

为什么 LOAD DATA IGNORE 结束了，仍然不能说全部导入成功？

因为 IGNORE 的目标是继续处理可用行。导入语句完成只能说明语句执行到了结束位置，不能说明每条输入行都通过 CHECK。应把成功落表数量、警告数量和警告明细一起写入批次结果。

能不能用 SELECT @@warning_count 代替 SHOW COUNT(*) WARNINGS？

它可以读取计数，但它本身属于普通查询，读取之后会影响当前诊断消息列表。需要同时保留明细时，先用 SHOW COUNT(*) WARNINGS，再用 SHOW WARNINGS；不要让计数查询成为中间步骤。

把 max_error_count 调大，能让违规行重新导入吗？

不能。它只影响服务器保留多少条诊断消息，不改变 CHECK 表达式，也不改变 IGNORE 对违规行的处理。要恢复被跳过的行，应修正源数据后重新导入，或由应用层按审计结果生成修复批次。

这个方案会自动保存原始失败行吗？

不会。警告消息属于诊断信息，通常能告诉你约束相关的级别、错误码和消息，但原始 CSV 行、业务批次号和重试策略仍应由客户端或导入服务保存。

最后的落地清单

如果你的批量任务确实允许“合法行先落表”，可以按这个顺序落地：

1. 在目标表定义清晰、可解释的 CHECK，并给约束命名。
2. 使用同一连接执行 LOAD DATA ... IGNORE、SHOW COUNT(*) WARNINGS 和 SHOW WARNINGS。
3. 不要在诊断语句前插入普通 SELECT，也不要只保存命令退出码。
4. 客户端读取警告结果集，并附加批次、源文件和连接上下文后持久化。
5. 验收时同时对照落表行数、跳过行数、警告总数和实际保存的明细数量。

这样处理之后，LOAD DATA IGNORE 才真正成为可审计的批量导入策略：它负责让可用数据继续前进，CHECK 负责守住业务边界，而客户端负责把被跳过的原因保留下来。