MySQL字段类型不匹配导致插入失败时，应先用DESCRIBE或SHOW COLUMNS确认字段定义，再根据业务语义选择显式转换（CAST/CONVERT）、新增字段迁移、添加JSON校验约束或修复应用层SQL逻辑，严禁依赖隐式转换或关闭严格模式长期运行。
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 也认
