MySQL的INSERT IGNORE仅跳过主键或唯一约束冲突，不处理类型、长度等格式错误；真正“忽略格式错误”需应用层清洗或触发器静默修正。
MySQL用INSERT IGNORE跳过唯一冲突，但不处理格式错误
INSERT IGNORE 只对违反 PRIMARY KEY 或 UNIQUE 约束的行生效，比如重复 email；它完全不检查字段类型、长度、正则格式等。如果你插入 'abc' 到 INT 字段，MySQL 仍会报错（如 Truncated incorrect integer value），IGNORE 无效。
真正能“自动忽略格式错误”的方案，必须靠前置清洗或数据库层校验机制：
- 应用层提前用正则/类型转换过滤非法值，再批量插入合法数据
- 用
BEFORE INSERT触发器 +SIGNAL SQLSTATE '45000'拦截非法格式，但这是“报错中止”，不是“忽略”——想实现“忽略”，得在触发器里把非法值转成NULL或默认值，而非抛错 - MySQL 不支持类似 PostgreSQL 的
ON CONFLICT DO NOTHING那种带条件的忽略语法
PostgreSQL用ON CONFLICT DO NOTHING真正跳过冲突行
PostgreSQL 的 ON CONFLICT 是目前最接近“自动忽略”的标准方案，但它也只响应约束冲突（主键、唯一索引），不响应格式错误。例如：
INSERT INTO users (email, name)
VALUES ('a@b.c', 'Alice'), ('x@y.z', 'Bob')
ON CONFLICT (email) DO NOTHING;
如果 email 字段定义为 TEXT，那任何字符串都能插进去；但如果字段是 EMAIL 自定义域并带 CHECK 约束，违反时仍会报错，ON CONFLICT 不接管。
所以关键点在于：约束定义要精准。常见做法是：
- 给邮箱字段加
CHECK (email ~ '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$') - 但注意：这个
CHECK会让非法邮箱直接报错，无法“忽略”——想忽略，就得去掉该约束，改用触发器做静默修正 - 或者接受“部分失败”，用
pg_bulkload工具配合ERRORS参数把坏行导出到错误文件，主流程继续
SQL Server没有原生“忽略格式错误”机制
SQL Server 的 BULK INSERT 支持 MAXERRORS 和 ERRORFILE，但它只跳过解析失败的行（如字段数不对、类型无法转换），不跳过违反 CHECK 或 FOREIGN KEY 约束的行。例如：
- 源文件某行 email 是
'foo'，目标列为NVARCHAR(255)→ 插入成功（字符串无问题） - 同一行插入到带
CHECK (email LIKE '%@%')的列 → 直接报错，MAXERRORS不起作用 -
BULK INSERT不支持在导入时动态修正字段值，必须靠前置 ETL 或目标表触发器
实际项目中更可靠的做法是：先 BULK INSERT 到一个无约束的 staging 表，再用 INSERT ... SELECT 带 WHERE 过滤和 TRY_CAST/TRY_CONVERT 处理类型转换，把非法行筛掉。
真正安全的“忽略”必须分两层：解析层 + 语义层
所有数据库都把“格式错误”拆成两类，处理方式完全不同：
-
解析层错误：CSV 字段数不匹配、数字字段含字母、时间格式无法识别 →
BULK INSERT MAXERRORS、LOAD DATA INFILE IGNORE、pg_bulkload可跳过 -
语义层错误：通过了类型检查，但违反业务规则（如邮箱不含 @、年龄 > 150、状态值不在枚举中）→ 必须靠
CHECK约束或触发器拦截，而“忽略”意味着你主动放弃校验，或用触发器静默转成默认值
最容易被忽略的是：触发器里的修正逻辑必须幂等且无副作用。比如用 SET NEW.email = NULLIF(NEW.email, '') 没问题，但用 SET NEW.created_at = NOW() 在批量导入时会导致所有行时间戳相同——这不是忽略错误，是制造新问题。
