MySQL字段类型不匹配导致插入失败时,应先用DESCRIBE或SHOW COLUMNS确认字段定义,再根据业务语义选择显式转换(CAST/CONVERT)、新增字段迁移、添加JSON校验约束或修复应用层SQL逻辑,严禁依赖隐式转换或关闭严格模式长期运行。
遇到 ERROR 1366 (HY000) 或 ERROR 1265 (01000) 这类报错,基本是数据类型与字段定义冲突,比如往 TINYINT 插字符串、向 DATE 插 '2025-13-01'、或 NOT NULL 字段插了 NULL(且没设默认值)。修复核心不是“强行转”,而是确认业务语义后选对方式。
DESCRIBE table_name; 或 SHOW COLUMNS FROM table_name; 看清字段当前类型、是否允许 NULL、有无 DEFAULT
'',时间字段别传非法格式字符串SET sql_mode = ''; 关闭严格模式,但上线前必须改回,否则会静默截断或转成零值ALTER TABLE ... MODIFY COLUMN 直接扩类型而不验证存量数据,比如把 VARCHAR(10) 改成 VARCHAR(50) 前,得先确认现有数据没超长执行 ALTER TABLE t MODIFY COLUMN c INT 却发现原来存的 '123abc' 变成 123,这是 MySQL 隐式转换在作祟。不是 bug,是设计行为——但业务上往往不可接受。
SELECT c, LENGTH(c), c+0 FROM t WHERE c REGEXP '^[^0-9]'; 检查非纯数字内容c_raw VARCHAR(255) 字段,再用 UPDATE t SET c_raw = c; 迁移CAST() 或 CONVERT() 显式处理,例如:UPDATE t SET c = CAST(c AS SIGNED) WHERE c REGEXP '^[0-9]+$';并单独处理异常行
ALTER TABLE ... CHANGE COLUMN 比 MODIFY 更安全,因为它强制重命名(哪怕同名),能避免某些隐式行为JSON 类型字段插入了 '{a:1}'(key 没引号)或 '{"x":}'(值缺失),会导致 INSERT 失败或后续 JSON_EXTRACT() 返回 NULL
,但不会报明显错误——容易漏检。
CREATE TABLE t (j JSON CHECK (JSON_VALID(j)));
SELECT id, j FROM t WHERE NOT JSON_VALID(j); 找出来REPLACE() 简单替换,JSON 格式敏感。推荐导出后用 Python/Node.js 脚本校验并修正,再批量更新JSON_VALID() 判断,别依赖数据库拦截DATE/DATETIME 字段出现 0000-00-00,通常是插入了非法日期(如 '0000-01-01')且 SQL mode 包含 ALLOW_INVALID_DATES;而字段突然变成当前时间,大概率是定义里带了 CURRENT_TIMESTAMP 默认值或更新触发器。
SHOW CREATE TABLE t; 看字段有没有 DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
--sql-mode="STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE",或运行时 SET sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE';
UPDATE t SET dt = NULL WHERE dt = '0000-00-00';(前提是字段允许 NULL)
0000-00-00,统一用 NULL —— 语义清晰,索引友好,ORM 也认