JSON_EXTRACT读取嵌套对象或数组时路径必须以$开头，用.访问对象键、[n]访问数组元素，特殊键名需双引号包裹（如$."user name"），返回值为带引号的JSON类型，可用JSON_UNQUOTE或->>去除引号。

JSON_EXTRACT 读取嵌套对象或数组时路径怎么写？

JSON_EXTRACT 的第二个参数是 JSON 路径表达式，必须以 $ 开头。

路径中用点号（.）访问对象键，用方括号（[n]）访问数组元素。

常见错误是漏掉 $，或者混淆单双引号。路径字符串本身要用单引号包裹，里面不能混用双引号。

• 键名含空格或特殊字符（如 user name）必须用双引号包在路径里：'$."user name"'
• 访问数组第一个元素写成 '$[0]'，不是 '$.[0]'
• 多层嵌套如 {"data": {"items": [{"id": 1}]}}，取 id 是 '$.data.items[0].id'
• 如果路径不存在，JSON_EXTRACT 返回 NULL，不是报错

为什么 SELECT JSON_EXTRACT(col, '$.name') 返回带双引号的字符串？

这是正常现象。JSON_EXTRACT 返回的不是普通 SQL 字符串，而是 JSON 类型的结果。

它会保留 JSON 的原始表示形式，可能是带引号的字符串、数字，或者布尔值。

例如字段里存的是 {"name": "Alice"}，那么 JSON_EXTRACT(col, '$.name') 取出的结果会是 "Alice"。注意，双引号是结果的一部分，而且它的类型仍然是 JSON。

• 要去掉引号转成普通字符串，得用 JSON_UNQUOTE(JSON_EXTRACT(col, '$.name'))，或者直接用更简洁的 col->>'$.name'（MySQL 5.7+）
• -> 等价于 JSON_EXTRACT，->> 等价于 JSON_UNQUOTE(JSON_EXTRACT(...))
• 在 ORDER BY 或 WHERE 中比较字符串时，不加 JSON_UNQUOTE 可能导致隐式类型转换异常，尤其和 VARCHAR 字段对比时

JSON_EXTRACT 在 WHERE 条件里性能很差怎么办？

JSON_EXTRACT 无法使用普通索引，每次都要全表解析 JSON 字段，大数据量下会非常慢。

• MySQL 5.7+ 支持生成列（generated column）+ 虚拟列索引：

  ALTER TABLE t ADD name_text VARCHAR(100) AS (JSON_UNQUOTE(JSON_EXTRACT(data, '$.name'))) STORED;

  然后 CREATE INDEX idx_name ON t(name_text);
• 如果只查是否存在某个键，用 JSON_CONTAINS_PATH(data, 'one', '$.name') 比 JSON_EXTRACT 快，它不解析值，只检查路径结构
• 避免在 WHERE 中对 JSON_EXTRACT 结果做函数运算，比如 UPPER(JSON_EXTRACT(...))，会彻底阻止任何潜在优化

JSON_EXTRACT 读取布尔或 NULL 值时要注意什么？

JSON 中的 true/false/null 被提取后，仍是对应的 JSON 类型。

但 MySQL 会尝试转换：布尔转为 0/1，null 转为 SQL NULL。

问题在于歧义。JSON 里的 "false"（字符串）和 false（布尔）提取结果并不相同。

• 判断是否为布尔 false，不能只靠 = 0，因为字符串 "0"、数字 0、布尔 false 都可能转成 0
• 安全做法是先用 JSON_TYPE(JSON_EXTRACT(col, '$.flag')) = 'BOOLEAN' 确认类型，再结合 JSON_EXTRACT 取值
• 提取 null 值时，JSON_EXTRACT 返回 JSON null，和 SQL NULL 行为一致，但 IS NULL 判断有效，= NULL 无效

使用 JSON_EXTRACT 时最容易出错的地方

实际使用时，重点不要只放在语法能不能跑通。

• 路径写错
• 类型没有处理
• 在 WHERE 里乱用

这三个地方出问题的概率，远高于语法本身。

《夸克》非常好用的免费AI浏览器

下载APP查看