json_value提取嵌套属性时路径必须以$开头且键名用双引号包裹,如"$."first name"."last-name"";仅返回标量值,对象或数组路径返回null,需先用json_extract验证路径有效性。

JSON_VALUE 提取嵌套属性时路径写法必须用双引号包裹键名
MySQL 和 SQL Server 的 JSON_VALUE 都要求 JSON 路径表达式(path expression)中所有对象键名必须用双引号包围,哪怕它看起来“合法”——比如 "user.name" 是错的,必须写成 "$.user.name" 或更安全的 "$.\"user\".name"。常见错误是直接写 user.name 或漏掉根符号 $,导致返回 NULL 且无报错提示。
实际使用建议:
- 始终以
$开头,明确从 JSON 根开始解析 - 嵌套对象键含空格、点号、连字符或大小写混用时,必须用反斜杠转义加双引号,例如
"$.\"first name\".\"last-name\"" - SQL Server 对路径语法更严格,不支持 MySQL 风格的
->操作符,只认标准 JSON path(如$.data.items[0].id) - MySQL 5.7+ 支持,但 8.0+ 才完整兼容 RFC 7396;旧版遇到
null值嵌套可能静默失败
NULL 返回不是数据问题,大概率是路径不匹配或类型不一致
JSON_VALUE 只提取标量值(string/number/true/false/null),如果目标路径存在但指向一个对象或数组,函数强制返回 NULL —— 不会报错,也不会自动转字符串。这是最容易被忽略的“假失败”。
排查步骤:
- 先用
JSON_EXTRACT(MySQL)或JSON_QUERY(SQL Server)验证路径是否真能定位到内容,例如JSON_EXTRACT(json_col, "$.config") - 确认目标字段确实是字符串:若原 JSON 中写的是
"count": 42,用JSON_VALUE提取"$.count"会返回'42'(字符串),但若字段是"enabled": true,JSON_VALUE无法提取 boolean,只能返回 NULL - MySQL 中区分
JSON_VALUE(json_col, path RETURNING CHAR)和默认行为,后者隐式转换可能截断长字符串
跨数据库移植时注意 RETURNING 子句的兼容性差异
SQL Server 支持 RETURNING 明确指定返回类型(如 RETURNING INT),MySQL 8.0.22+ 才引入该语法,且仅支持 CHAR 和 JSON 类型;PostgreSQL 根本没有 JSON_VALUE,得用 ->> 操作符替代。
详细的 Three.js 3D 图形参考,涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
可移植写法建议:
- 优先用
CAST(JSON_VALUE(col, '$.field') AS SIGNED)替代RETURNING INT,兼容 MySQL 5.7+ - 避免在 WHERE 条件中直接对
JSON_VALUE结果做数值比较,例如WHERE JSON_VALUE(data, '$.score') > 80实际比较的是字符串,应显式CAST(... AS DECIMAL) - SQL Server 中若路径不存在,
JSON_VALUE默认返回 NULL;MySQL 则取决于json_table或函数调用上下文,行为不统一
性能隐患:JSON_VALUE 在 WHERE 或 JOIN 中不可用索引
无论 MySQL 还是 SQL Server,JSON_VALUE 都是运行时计算函数,无法利用普通 B-tree 索引。如果高频按某个 JSON 字段查询,别指望加个函数索引就万事大吉。
真实优化路径:
- MySQL 5.7+ 可建虚拟列 + 索引:
ALTER TABLE t ADD score INT AS (JSON_VALUE(data, '$.score')) STORED,再对score加索引 - SQL Server 需用
PERSISTED计算列:score AS JSON_VALUE(json_col, '$.score') PERSISTED,然后索引该列 - 避免在大表上 SELECT 中大量调用
JSON_VALUE,尤其嵌套深、重复路径多时,CPU 开销明显上升
嵌套越深,路径越容易写错;类型越模糊,NULL 越难排查。别依赖“看起来应该对”,每次路径都用 JSON_EXTRACT 或 JSON_QUERY 先探一遍值结构。










