JSON_PRETTY()仅美化SQL查询中的JSON字段值，无法处理磁盘上的MySQL错误日志文件；错误日志由log_sink_json组件生成标准缩进JSON，应使用jq等工具查看分析。
JSON_PRETTY() 只能美化字段值，不能处理错误日志文件
很多人误以为 JSON_PRETTY() 能直接格式化 MySQL 的错误日志（比如 /var/log/mysql/error.log.00.json），但事实是：它只作用于 SQL 查询中返回的 JSON 字段值，对磁盘上已写入的 JSON 日志文件完全无效。错误日志的 JSON 格式由 log_sink_json 组件控制，输出即为标准缩进 JSON，无需、也无法用 SQL 函数再“美化”。
排查 JSON 错误日志时，别在 SELECT 里硬套 JSON_PRETTY()
如果你试图用类似 SELECT JSON_PRETTY(log_content) FROM error_log_view 的方式去“解析日志”，会失败——因为错误日志不是存进数据库表里的，它压根不经过 SQL 引擎。MySQL 的 JSON 错误日志是独立写入文件的纯文本流（只是内容为 JSON），JSON_PRETTY() 没法读取文件、也没法反向解析日志行。
- 想人工查看某条 JSON 日志？直接用
jq工具：jq '.' /var/log/mysql/error.log.00.json | head -20 - 想查特定错误类型？用
grep '"severity":"ERROR"' /var/log/mysql/error.log.00.json - 想确认 JSON 是否合法？
jq -n 'true' 2>/dev/null || echo "jq not installed"先验证环境
真正需要 JSON_PRETTY() 的场景：调试表中 JSON 字段内容
当你的业务表里有 details json 这类字段，且插入的是紧凑格式（如 {"id":1,"tags":["a","b"]}），用 JSON_PRETTY() 能让查询结果可读性大幅提升：
SELECT id, JSON_PRETTY(details) AS formatted FROM user_test WHERE id = 5;
注意两点：
-
JSON_PRETTY()输入必须是合法 JSON 值，传入字符串（如'{"a":1}'）可以，但传入 NULL 或非法字符串（如'{a:1}'）会直接报错ERROR 3141 (22032): Invalid JSON text - 它不改变存储，只影响查询输出；生产环境大量使用可能轻微增加 CPU 开销，仅限调试或管理端展示
JSON 日志排障最常被忽略的三件事
很多问题其实和 JSON_PRETTY() 无关，而是配置链断裂：
- 没运行
INSTALL COMPONENT 'file://component_log_sink_json';——组件未加载，log_error_services再怎么设也白搭 -
log_error是相对路径或没权限（比如设成log_error = error.log或指向/tmp但mysql用户无写权）——JSON 文件根本不会生成，更别说查看 - 用
SET GLOBAL log_error_services = '...'但忘了SET PERSIST——重启后配置丢失，日志又变回纯文本
JSON 日志本身已是结构化格式，是否“美观”取决于你用什么工具看；而能否稳定产出，取决于那几行关键的组件安装与路径配置，不是函数调用的事。
