mysql 8.0 错误日志不记录 json 函数错误（如 json_extract 返回 null、json_valid() 为 0），仅记录服务级崩溃、启动失败等底层问题；json 相关报错属 sql 层语义错误，直接返回客户端，不写入 error.log。
MySQL 8.0 的错误日志本身不记录 JSON 解析或操作错误（比如 JSON_EXTRACT 返回 NULL、JSON_VALID() 为 0），它只记录服务级崩溃、启动失败、权限拒绝、磁盘满等底层问题。真正和 JSON 相关的“错误”，实际发生在 SQL 执行层，报错会直接返回给客户端，**不会写进 error log 文件**。
为什么在 error log 里找不到 JSON 函数报错？
MySQL 的错误日志（log_error 指向的文件）只捕获服务器进程级异常，而 JSON 函数错误属于 SQL 执行时的语义错误，由 SQL 层抛出并立即返回，例如：
ERROR 3143 (42000): Invalid path expressionERROR 3149 (HY000): Path expression is not found in the JSON dataERROR 3153 (HY000): Cannot create a JSON value from a string with CHARACTER SET 'binary'
这些都**不会落盘到 error.log**，而是由客户端（如 MySQL Shell、Navicat、应用连接池）直接接收。所以你翻遍 /var/log/mysql/error.log 或 hostname.err，也找不到它们。
那 JSON 相关问题该查什么日志？
要看 JSON 逻辑出错，得换地方找线索：
- 应用层日志：检查你的 Java/Python/PHP 应用是否捕获并打印了 MySQL 错误码和 SQL 状态，这是最直接的来源
- 通用查询日志（
general_log）：开启后可看到完整 SQL + 客户端 IP + 时间戳，配合应用日志能定位哪条语句触发了 JSON 报错 -
performance_schema.error_log表（仅当启用了log_error_services = log_filter_internal; log_sink_perfschema）：它只记录服务器级错误，对 JSON 函数无效；别白费劲查这个表 - 慢查询日志（
slow_query_log）：如果 JSON 处理导致严重性能退化（比如在大字段上反复JSON_EXTRACT），可能被记入，但不是错误本身
怎么快速验证 JSON 数据结构再执行 JSON_TABLE？
避免运行时报错的实操顺序必须是：
- 先确认字段是合法 JSON：
SELECT id, JSON_VALID(json_col) AS valid FROM t WHERE id = 123;—— 返回0就别往下走了 - 看原始结构：
SELECT JSON_PRETTY(json_col) FROM t WHERE id = 123;—— 别靠猜，直接看缩进和类型 - 试路径提取：
SELECT JSON_EXTRACT(json_col, '$.items[*].price') FROM t WHERE id = 123;—— 成功返回数组说明路径层级对，失败再调$.items或$逐层试 - 最后才写
JSON_TABLE，且确保主路径用单引号包裹、数组用'$[*]'、对象字段用'$.field'，子路径不能带[*]
路径写错一次就中断查询，没有“静默失败”——这不是 bug，是设计如此。别指望日志帮你兜底，得靠前置探查。
