MySQL 8.0 JSON函数报错Invalid JSON text：快速定位非法数据行

遇到“Invalid JSON text”报错时，许多开发者会感到困惑。MySQL 8.0提供了JSON_VALID()函数，可实现对非法JSON数据行的批量筛查，且不会因异常中断查询，相比逐条测试INSERT或SELECT语句更为高效。

使用JSON_VALID()批量筛查非法JSON值

在WHERE条件中结合JSON_VALID()函数，返回0表示该行的JSON语法存在问题。查询整张表可使用以下语句：SELECT id, json_col FROM table_name WHERE JSON_VALID(json_col) = 0;。如需同时清理空字符串或NULL值，可增加条件：WHERE json_col = '' OR json_col IS NULL。需注意JSON_VALID('')返回0，而JSON_VALID(NULL)返回NULL，因此空值需单独判断。

若字段允许为空但业务逻辑上不允许为空，建议在建表时添加CHECK约束（MySQL 8.0.16及以上版本支持）：CHECK (json_col IS NOT NULL AND JSON_VALID(json_col))。此方式可从源头阻止脏数据入库。

报错信息中“at position 0”的常见含义

位置0出错通常表示数据完全不符合JSON格式。常见原因包括：空字符串''、纯空白字符（空格或换行）、字符串形式的'null'（注意区别于JSON字面量null），或未传值导致字段默认为''（如MyBatis-Plus未设置默认值）。

几个关键区分点：JSON_VALID('')返回0，JSON_VALID('null')返回1（合法），JSON_VALID("null")返回0（单引号包裹双引号属于非法格式）。Java侧使用Jackson序列化时，应确保对象非空后再转换为字符串；若可能为空，应显式写为{}或[]，避免传入空字符串。在MyBatis-Plus中，可为JSON字段添加@TableField(fill = FieldFill.INSERT)并配合自动填充逻辑，有效避免空字符串入库。

结合Last_SQL_Error反向定位复制或导入失败源

当主从复制受阻或LOAD DATA报错，且Last_SQL_Error提示“position 0”时，可检查对应SQL的VALUES部分，通常问题源于某行JSON字段被拼写为''或'{...'（缺少结尾括号）。

定位方法如下：执行SHOW BINLOG EVENTS IN 'xxx' FROM yyy LIMIT 1（从Exec_Master_Log_Pos向前推算）找到原始SQL，将报错SQL复制出来后，在本地使用SELECT JSON_VALID(), 逐个参数测试，空值或畸形参数可快速定位。此外，从库版本低于主库时，JSON_VALID()行为一致，但CAST(... AS JSON)可能因sql_mode差异提前失败，需留意此情况。

数据库约束是最后一道防线

开发环境测试正常而线上报错，通常是因为测试数据未覆盖空值路径。仅靠代码中StringUtils.isNotBlank()判断远远不够，MySQL对JSON的校验比应用层更为严格。

最佳实践是在建表时直接添加CHECK约束：feature_data JSON CHECK (JSON_VALID(feature_data) AND feature_data != '')。不建议使用TEXT类型存储JSON再手动解析，这样既失去自动校验能力，也无法使用->操作符和JSON索引。若已存在脏数据，可先用UPDATE ... SET json_col = COALESCE(NULLIF(json_col, ''), '{}') WHERE JSON_VALID(json_col) = 0;兜底处理，再添加约束。

需要指出的是，JSON_VALID()返回1但后续JSON_EXTRACT()无法取到值的“合法垃圾”数据（如{"name": null}或{}）更具挑战性。这类语义问题数据库层面无法管控，需依赖业务逻辑层和团队约定来解决。工具能够拦截格式错误，但无法阻止业务上的“合理空值”。