MySQL JSON_TABLE 多个 NESTED PATH 为什么会补出 NULL 行

使用 MySQL JSON_TABLE() 把一个 JSON 对象拆成关系行时，如果在同一个 COLUMNS 中写了多个并列的 NESTED PATH，结果里出现一组列为 NULL 并不代表原 JSON 丢了字段。MySQL 会让这些 sibling nested paths 依次产出记录：当前路径有数据时，另一条路径的列对当前行补 NULL，总行数通常是各路径产出行数之和，而不是两组数组的笛卡尔积。

排查这类结果时，先把每个 NESTED PATH 看成独立的行来源，再决定是否用 WHERE 过滤某一分支；不要把补出的 NULL 当成 JSON_TABLE 解析失败。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/json-table-functions.html

先用一个最小例子复现 NULL 行

下面的 JSON 只有一个外层对象，但它同时有 b 和 c 两个数组。查询把两条路径放在同一个 COLUMNS 中，正好能看到结果行的来源。

-- 用一个外层对象同时提供 b、c 两个数组，观察两条路径的行来源
SELECT jt.id, jt.b_value, jt.c_value
FROM JSON_TABLE(
  '[{"id": 1, "b": [11, 12], "c": ["x", "y"]}]',
  '$[*]' COLUMNS (
    id INT PATH '$.id',
    NESTED PATH '$.b[*]' COLUMNS (
      b_value INT PATH '$'
    ),
    NESTED PATH '$.c[*]' COLUMNS (
      c_value VARCHAR(10) PATH '$'
    )
  )
) AS jt;

这个对象的 b 有两项，c 也有两项，所以结果是四行：前两行来自 b 路径，c_value 补为 NULL；后两行来自 c 路径，b_value 补为 NULL。外层列 id 会随每个结果行重复。

为什么多个 NESTED PATH 不是笛卡尔积

关键在于这些路径是同一层 COLUMNS 里的 sibling nested paths。MySQL 文档对它们的定义是“逐个处理”：一条路径正在生成记录时，另一条 sibling 路径的列设置为 NULL。因此两组数组长度分别为 2 和 2 时，结果是 2 + 2 = 4 行，而不是 2 × 2 = 4 行的配对关系。长度改成 2 和 3 后，结果会是 5 行，也不会自动把 b[0] 与 c[0] 配成一行。

这也解释了两个常见误判：

• 看到 c_value IS NULL，不能直接断定 JSON 中没有 c；它可能只是当前行来自 b 路径。
• 不能把两条路径的序号直接放在一起当作同一组数组下标；它们的记录生成范围不同。

只要一条分支时，用 WHERE 过滤结果

如果业务只想保留有 b 数组元素的行，可以在 JSON_TABLE 外层过滤。这样做改变的是最终查询结果，不会改变 JSON_TABLE 内部生成 sibling 路径记录的规则。

-- 只保留 b 路径产生的记录，过滤掉 c 路径补出的 NULL 行
SELECT jt.id, jt.b_value
FROM JSON_TABLE(
  '[{"id": 1, "b": [11, 12], "c": ["x", "y"]}]',
  '$[*]' COLUMNS (
    id INT PATH '$.id',
    NESTED PATH '$.b[*]' COLUMNS (b_value INT PATH '$'),
    NESTED PATH '$.c[*]' COLUMNS (c_value VARCHAR(10) PATH '$')
  )
) AS jt
WHERE jt.b_value IS NOT NULL;

如果要保留两类分支，就不要用 b_value IS NOT NULL AND c_value IS NOT NULL，因为 sibling 语义下同一行本来就只会有一条路径填值。可以用 WHERE b_value IS NOT NULL OR c_value IS NOT NULL 保留两边，或者给两条路径增加来源标记后再做聚合。

用 FOR ORDINALITY 标记当前路径内的序号

FOR ORDINALITY 适合回答“这一条路径产出的第几行”，但不要把它理解为跨所有 sibling 路径共享的全局计数器。需要分别追踪两组数组时，可以在各自的 NESTED PATH 中声明序号列：

-- 两个序号列分别属于各自的 NESTED PATH，不构成全局配对下标
SELECT jt.id, jt.b_pos, jt.b_value, jt.c_pos, jt.c_value
FROM JSON_TABLE(
  '[{"id": 1, "b": [11, 12], "c": ["x", "y"]}]',
  '$[*]' COLUMNS (
    id INT PATH '$.id',
    NESTED PATH '$.b[*]' COLUMNS (
      b_pos FOR ORDINALITY,
      b_value INT PATH '$'
    ),
    NESTED PATH '$.c[*]' COLUMNS (
      c_pos FOR ORDINALITY,
      c_value VARCHAR(10) PATH '$'
    )
  )
) AS jt;

此时 b_pos 只在 b 分支中编号，c_pos 只在 c 分支中编号。若业务真正需要把 b 与 c 按相同下标配对，应先分别展开成可识别的关系结果，再按明确的键或序号连接，不能依赖两个 sibling 路径自动配对。

排查时记住这三个判断

• 先看行来源：某一列为 NULL，先检查同一行是否由另一条 NESTED PATH 产生。
• 再看行数：并列路径通常按各自产出数相加，不要按数组长度相乘推断。
• 最后做过滤：用 WHERE 选择分支，用 FOR ORDINALITY 标记当前分支序号；需要跨数组配对时改用显式关系连接。

常见问题

为什么没有子数组也可能看到一行？

NESTED PATH 没有匹配时，MySQL 可以产生一条 NULL 补全行。应结合外层键和嵌套列一起判断，不要只看某个嵌套列。

能不能用 WHERE 把 NULL 补行变成内连接效果？

可以。针对某条嵌套路径列写 IS NOT NULL，就能保留有该路径数据的结果；这属于查询层筛选，不是改变 JSON_TABLE 的路径语义。