mysql 8.0 json复制报错主因是主从解析行为不一致，包括空值处理、嵌套结构、非法转义、sql_mode和collation差异，需通过last_sql_error定位、版本比对、触发器校验及主从参数严格同步来解决。
MySQL 8.0 中 JSON 字段引发的复制报错，根源往往不在 JSON 本身，而在主从节点对 JSON 值的解析行为不一致——尤其是 MySQL 5.7 与 8.0 之间、或 8.0.x 小版本之间对空值、嵌套结构、非法转义的容忍度差异。
MySQL 8.0 复制中断时先查 Last_SQL_Error 里的 JSON 相关关键词
执行 SHOW SLAVE STATUS\G 后，重点盯住 Last_SQL_Error 字段。只要错误信息里出现以下任意一项，基本可锁定是 JSON 解析层面的兼容性问题：
-
Invalid JSON text（常见于从库 MySQL 版本低于主库，或sql_mode不同） -
JSON document may not contain NULL member names（主库插入了键为null的 JSON 对象，但从库拒绝解析） -
Malformed JSON path（主库用了 8.0.27+ 新增的大小写不敏感列名，但从库是 8.0.26 或更早） -
Cannot create a JSON value from a string with CHARACTER SET 'binary'（典型字符集错配，比如主库用utf8mb4存 JSON，从库表字段没设COLLATE utf8mb4_0900_as_cs）
这类报错不会伴随 GTID 冲突或主键重复，而是直接卡在 SQL 线程解析阶段，Slave_SQL_Running 变为 No，且 Seconds_Behind_Master 停滞不动。
JSON_EXTRACT 和 ->> 在不同版本中对空值/缺失路径的返回差异
MySQL 5.7 默认对不存在的 JSON 路径返回 NULL；而 MySQL 8.0.22+ 在严格模式下可能抛出警告甚至错误（取决于 sql_mode 是否含 STRICT_TRANS_TABLES）。更隐蔽的是：->> 操作符会隐式调用 JSON_UNQUOTE()，若目标值本身就是 NULL 或路径不存在，8.0 某些小版本会返回空字符串 ''，而 5.7 返回 NULL ——这会导致从库执行 UPDATE ... SET json_col = json_col->>'$.foo' 时类型不匹配失败。
验证方法：
SELECT
JSON_EXTRACT('{"a": null}', '$.a') AS ex,
'{"a": null}'->>'$.a' AS arrow,
'{"b": 1}'->>'$.a' AS missing;
在主从分别执行，比对三列结果是否一致。不一致即为潜在复制风险点。
主从 sql_mode 和 collation 必须完全一致，尤其涉及 JSON 函数时
JSON 函数如 JSON_SET、JSON_REPLACE 的行为直接受 sql_mode 影响。例如：
- 主库启用了
PIPES_AS_CONCAT，而从库没启用 → 某些含||的 JSON 构造表达式在从库被当作逻辑或运算，报错 - 主库表字段定义为
json_col JSON COLLATE utf8mb4_0900_as_cs，从库建表时漏了COLLATE→ 插入含 emoji 的 JSON 时，从库因排序规则不支持 4 字节字符而拒绝 - 主库
sql_mode包含ANSI_QUOTES，而从库没有 → 主库用双引号写 JSON 字符串（"{\"key\":\"val\"}"）能过，从库解析时报错
检查命令：
SELECT @@sql_mode, @@collation_database, @@collation_server;
务必确保主从输出**逐字相同**。差异项必须统一，不能靠“差不多”蒙混。
用 JSON_VALID() + 触发器在主库拦截非法 JSON 写入
与其等复制到从库才爆错，不如在主库就堵住源头。在写入 JSON 字段前加校验：
DELIMITER $$
CREATE TRIGGER validate_css_json BEFORE INSERT ON elements
FOR EACH ROW
BEGIN
IF NOT JSON_VALID(NEW.css) THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid JSON in css column';
END IF;
END$$
DELIMITER ;
注意：该触发器仅对 INSERT 生效；UPDATE 需另建一个。同时建议在应用层也做 ObjectMapper.readTree() 预检，避免把校验压力全压给数据库。
真正棘手的不是语法错误，而是语义漂移：比如主库允许 {"id": ""} 这种空字符串 ID，从库因约束更严而拒绝。这种差异必须靠持续比对主从 SELECT JSON_TYPE(col), JSON_LENGTH(col) 输出来暴露，没法一劳永逸。
