严格模式下INSERT预检错误需用单条INSERT+显式字段名+异常捕获定位具体值；不能依赖ROW_COUNT()或SHOW WARNINGS；禁用临时关闭严格模式，应通过SELECT模拟校验逻辑预检。
☞☞☞☞点击夸克ai手把手教你，操作像呼吸一样简单！☜☜☜☜☜
MySQL 严格模式下 INSERT 失败时，如何捕获预检验阶段的错误
MySQL 在 STRICT_TRANS_TABLES 或 STRICT_ALL_TABLES 模式下，对数据合法性做前置校验，INSERT 语句在真正写入前就可能被拒绝。但这类错误不会出现在事务提交后——它发生在解析与校验阶段，所以不能靠 SELECT 或日志回查“哪些值被拦了”，得从执行过程本身抓。
用 INSERT ... SELECT + ROW_COUNT() 无法定位具体哪一行出错
很多人试图用 INSERT INTO t1 SELECT * FROM t2 后查 ROW_COUNT() 判断是否全量成功，但严格模式下只要某一行不合法（比如 NOT NULL 字段插了 NULL），整条语句就直接报错退出，ROW_COUNT() 返回 -1，且不告诉你哪一列、哪一行、哪个约束失败。
- 错误典型提示是：
ERROR 1364 (HY000): Field 'xxx' doesn't have a default value或ERROR 1265 (01000): Data truncated for column 'yyy' at row 1 - 注意：这里的
row 1是指SELECT结果集的第一行，不是源表物理行号，也未必对应原始数据顺序 - 如果用
LOAD DATA INFILE，错误位置会更模糊，连行号都可能不准
真正能定位问题的方案：用 INSERT ... VALUES 单条+异常捕获 + 显式字段列表
批量插入必须拆成单条，才能把错误绑定到具体值。关键不是“慢”，而是“可控”。配合显式字段名和客户端异常处理，才能知道 VALUES ('a', NULL, 'c') 中第二个值触发了 NOT NULL 约束。
- 务必写全字段名：
INSERT INTO t (a, b, c) VALUES (?, ?, ?)，避免因表结构变更导致隐式错位 - 使用支持逐条重试的驱动（如 Python 的
pymysql、Go 的database/sql），在except/if err != nil中打印完整VALUES和错误信息 - 不要依赖
SHOW WARNINGS：严格模式下多数校验失败是ERROR级别，不进 warning 栈 - 示例错误捕获逻辑：
try: cursor.execute("INSERT INTO user (name, age) VALUES (%s, %s)", ("Alice", None)) except pymysql.IntegrityError as e: print(f"Insert failed with values ('Alice', None): {e}")
想绕过严格模式临时验证？别用 SET sql_mode = ''
临时关闭严格模式看似能“让数据先存进去”，但后果严重：截断、静默转空字符串、默认值填充等行为会掩盖真实数据质量问题，后续查数、导出、ETL 都可能崩。
-
SET SESSION sql_mode = ''只影响当前连接，但并发环境下极易误伤其他逻辑 - 即使只读验证，也建议用
SELECT+CASE WHEN模拟校验逻辑，比如：SELECT id, name, CASE WHEN name IS NULL THEN 'name missing' END AS error FROM raw_data WHERE name IS NULL OR LENGTH(name) > 50;
- 真正的预检 SQL 应该是独立的
SELECT查询，而非依赖 INSERT 的副作用
最麻烦的点其实不在语法——而在于 MySQL 不提供“模拟插入并返回所有校验失败详情”的内置函数。你得自己把约束逻辑翻译成 SQL 表达式，或者接受单条执行的成本。这点容易被忽略，直到线上批量导入卡在第 8742 行却只报“Field 'x' doesn't have a default value”才反应过来：它根本没说 x 是哪个字段，也没说哪条记录。
