JSON_TABLE比JSON_CONTAINS更适合连接场景，因其将JSON数组展开为虚拟关系表，使优化器能正常关联、下推过滤并利用索引；而JSON_CONTAINS无法走索引，导致全表扫描和Using join buffer。
JSON_TABLE 为什么比 JSON_CONTAINS 更适合连接场景
直接在 JOIN 条件里用 JSON_CONTAINS 或 JSON_EXTRACT 做匹配，会导致无法走索引、全表扫描、执行计划显示 Using where; Using join buffer。而 JSON_TABLE 的核心价值是把 JSON 数组「一次性展开为虚拟关系表」，让优化器能按常规表做关联、下推过滤、甚至利用生成列+索引加速。
典型适用场景：订单表 orders 中 items 是 JSON 数组，需关联商品主表 products 查单价、类目等属性。
- 必须确保 JSON 字段内容结构稳定（如每个元素都有
product_id和qty） - MySQL 版本 ≥ 8.0.4，且 JSON 字段不能是 NULL（空数组可，NULL 值会让
JSON_TABLE返回空结果集） - 展开后行数可能远大于原表，注意内存临时表限制（
tmp_table_size/max_heap_table_size）
写对 JSON_TABLE 的 column 定义才能正确映射字段
JSON_TABLE 的 COLUMNS 子句不是简单取值，而是定义「如何从 JSON 路径提取并转类型」。常见错误是漏写 FOR ORDINALITY 导致无法区分同数组内重复 product_id，或用 PATH '$.id' 却没加 ERROR ON ERROR 导致某条记录解析失败就整行丢弃。
正确写法示例：
JSON_TABLE(
o.items,
'$[*]' COLUMNS (
idx FOR ORDINALITY,
product_id BIGINT PATH '$.product_id' ERROR ON ERROR,
qty INT PATH '$.qty' DEFAULT '0' ON EMPTY,
sku VARCHAR(64) PATH '$.sku' NULL ON EMPTY
)
) AS jt
-
FOR ORDINALITY生成序号列，避免多条相同product_id关联时笛卡尔爆炸 -
ERROR ON ERROR让解析失败的项跳过该行（而非中断整个查询），比默认的ERROR ON ERROR更健壮 -
DEFAULT '0' ON EMPTY比NULL ON EMPTY更适合数值聚合，避免SUM()被 NULL 短路
JOIN 时别忘了加 WHERE 过滤再展开，否则性能雪崩
先 JOIN 再 WHERE 和先 WHERE 再 JOIN 对 JSON_TABLE 影响极大。如果在 FROM 子句里直接写 JSON_TABLE(orders.items, ...)，MySQL 会先对所有订单展开 JSON，再过滤——哪怕你只查昨天的 100 条订单，也可能展开上百万行 item。
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
正确做法是：用派生表或 CTE 先限定主表范围，再对其 JSON 展开：
SELECT o.order_id, jt.product_id, jt.qty, p.name FROM ( SELECT order_id, items FROM orders WHERE created_at >= '2024-06-01' ) AS o JOIN JSON_TABLE(o.items, '$[*]' COLUMNS ( product_id BIGINT PATH '$.product_id', qty INT PATH '$.qty' )) AS jt ON TRUE JOIN products AS p ON p.id = jt.product_id;
- 外层
WHERE必须作用于原始表（如orders），不能写成jt.product_id = 123后置过滤 -
ON TRUE是必需的，因为JSON_TABLE不提供自然连接键；真正关联靠后续JOIN products - 若需按 item 属性过滤（如只查
qty > 5的项），把条件放在JSON_TABLE的WHERE子句里（MySQL 8.0.22+ 支持）
复杂嵌套或动态 key 怎么办？别硬扛 JSON_TABLE
JSON_TABLE 只支持静态路径（'$.items[*]'），遇到「不同订单 items 结构不一致」或「key 名动态生成（如 {"2024-06-01": {...}}）」，强行用 JSON_TABLE 会导致大量 NULL ON ERROR 和不可维护的 COLUMNS 列表。
此时更务实的选择是：
- 在应用层做两次查询：先查订单列表，再用
IN批量查对应商品，本地解析 JSON 组装 - 给 JSON 字段建生成列 + 索引，例如：
ALTER TABLE orders ADD COLUMN first_item_id BIGINT AS (JSON_EXTRACT(items, '$[0].product_id')) STORED，然后走普通索引关联 - 把高频查询的 JSON 字段拆到独立宽表（如
order_items_flat），用触发器或应用逻辑同步，换空间换查询稳定性
JSON_TABLE 不是银弹，它解决的是「结构化 JSON 数组的批量关系化」，而不是任意 JSON 的通用查询引擎。字段越规范、查询越固定，它越高效；反之，预处理或反范式化反而更省心。
