MySQL字段类型不匹配导致插入失败怎么办
遇到
ERROR 1366 (HY000)或
ERROR 1265 (01000)这类报错，基本是数据类型与字段定义冲突，比如往
TINYINT插字符串、向
DATE插
'2025-13-01'、或
NOT NULL字段插了
NULL（且没设默认值）。修复核心不是“强行转”，而是确认业务语义后选对方式。 先用
DESCRIBE table_name;或
SHOW COLUMNS FROM table_name;看清字段当前类型、是否允许
NULL、有无
DEFAULT检查出问题的 SQL，重点看值和字段是否逻辑匹配：数字字段别传空串
''，时间字段别传非法格式字符串 临时绕过（仅调试）可用
SET sql_mode = '';关闭严格模式，但上线前必须改回，否则会静默截断或转成零值 生产环境禁止用
ALTER TABLE ... MODIFY COLUMN直接扩类型而不验证存量数据，比如把
VARCHAR(10)改成
VARCHAR(50)前，得先确认现有数据没超长
ALTER TABLE修改字段类型时数据被截断或丢失
执行
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字段存了无效格式，查询报错
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()判断，别依赖数据库拦截
时间字段显示为 0000-00-00 或变成当前时间
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 也认 实际修复中最容易被忽略的是：没确认应用层是否还在持续写入非法值。修完表结构，必须同步检查代码里的 SQL 构造逻辑，否则几天后又回到原点。
