JSON_TABLE 是 MySQL 8.0.4+ 等数据库中将 JSON 数组或对象展开为关系行集的函数，用于 JOIN、WHERE 和聚合，适用“一对多”JSON 数据场景，需合法 JSON 输入与正确路径，性能开销大，不可替代应用层处理或全文匹配。
JSON_TABLE 是 MySQL 8.0.4+ 和 Oracle、SQL Server（2016+）中用于将 JSON 文本“展开”为关系行集的关键函数。它不是万能解析器，不能替代应用层处理，但能解决一个具体问题：把嵌套在 JSON 字段里的数组或对象，变成可 JOIN、可 WHERE、可聚合的临时表。
你不能用 JSON_TABLE 直接关联两个 JSON 字段，也不能靠它做全文语义匹配；它的作用很窄——把一段合法 JSON 拆成带列名的虚拟结果集，再和其他表做标准 SQL 关联。
JSON_TABLE 的典型使用场景
- JSON 字段里存的是「一对多」数据，比如商品详情中的
"tags": ["wireless", "bluetooth", "gaming"]，你想查所有带"gaming"标签的商品并统计数量 - 用户配置 JSON 中有
"roles": [{"id": 1, "name": "admin"}, {"id": 2, "name": "editor"}]，需按角色名称筛选用户 - 日志 JSON 中包含
"events"数组，想把每个事件拆成一行做时间排序或类型分组
这些场景下，不用 JSON_TABLE 就只能靠应用层遍历解析，或者写一堆 JSON_CONTAINS + UNION ALL 模拟展开，既难维护又没法走索引。
JSON_TABLE 必须传入合法 JSON，且路径要存在
JSON_TABLE 第一个参数必须是返回 JSON 值的表达式（如字段、函数调用），不是字符串字面量。常见错误：
- 写成
JSON_TABLE('{"a":1}', ...)→ 报错，因为字符串不是 JSON 类型值 - 字段本身是
VARCHAR类型存的 JSON 字符串 → 必须先用CAST(col AS JSON)转换，否则解析失败 - 路径写错，比如
$.items[0].name，但实际 JSON 里items是空数组或根本不存在 → 整行返回 NULL，不报错但结果为空
正确写法示例（MySQL）：
SELECT p.name, jt.tag
FROM products p,
JSON_TABLE(
p.details, '$.tags'
COLUMNS (
tag VARCHAR(50) PATH '$'
)
) AS jt
WHERE jt.tag = 'electronics';注意三点：
-
p.details是 JSON 类型字段，无需转换 -
'$.tags'是路径，指向一个数组；如果指向对象，需用'$.*'或明确键名 -
COLUMNS里PATH '$'表示取当前数组元素自身（因为tags是字符串数组）
和 ->>、JSON_CONTAINS 的性能与用途差异
-
->>只适合提取单个值做简单过滤，比如details->>'$.brand'= 'Apple'；它快，但无法展开数组 -
JSON_CONTAINS(details, '"Apple"', '$.brands')适合判断某个值是否在 JSON 数组里，但不能拿到该值所在行的其他上下文字段 -
JSON_TABLE开销明显更大：每次调用都要解析 JSON、构建临时行集、参与 JOIN；它只应在「必须把 JSON 数组当关系表用」时启用
如果你只是想查「哪些商品有 blue 颜色」，用 JSON_CONTAINS(details, '"blue"', '$.colors') 更轻量；只有当你需要「列出每个商品的每种颜色，并和颜色分类表关联」时，才轮到 JSON_TABLE 上场。
JSON_TABLE 的语法在不同数据库间差异不小，MySQL 不支持 NESTED PATH 多级展开，SQL Server 要求显式声明 WITH 子句，Oracle 对路径语法更严格。别直接复制粘贴跨库代码，先验证路径是否被识别、返回列类型是否匹配。最常被忽略的是：它不自动去重，也不跳过 NULL 元素——数组里有 null，就会生成一行 NULL 值。
