MySQL中JSON字段不能直接用于JOIN的ON条件，必须用->>提取并转为标量类型；推荐建STORED虚拟列加索引以提升性能，并注意NULL处理与跨库兼容性问题。
JOIN时直接用JSON字段做ON条件会失败
MySQL不允许把JSON类型字段直接用于JOIN的ON子句，比如写ON t1.data -> '$.id' = t2.id会报错Invalid JSON path expression或隐式转换失败。本质是JSON值不能参与等值比较运算，必须先转成标量类型。
必须用JSON_EXTRACT或->>提取后再JOIN
JSON_EXTRACT()返回JSON类型，仍不能直接比较；真正能用于JOIN的是->>操作符——它自动将提取结果转为字符串（含去引号），等价于CAST(JSON_EXTRACT(...) AS CHAR)。
-
t1.data ->> '$.user_id'→ 返回无引号字符串，可与t2.id（假设是INT或VARCHAR）安全比较 -
JSON_EXTRACT(t1.data, '$.user_id')→ 返回带引号的JSON字符串，如"123"，跟数字123比较会强制转换但不可靠，尤其遇到null或空格时易出错 - 若被关联字段是数字类型，建议显式转：
CAST(t1.data ->> '$.user_id' AS UNSIGNED)
性能差？得加虚拟列+索引
每次JOIN都执行->>是全表计算，无法走索引。真实场景下必须提前建虚拟列并索引：
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
ALTER TABLE orders ADD COLUMN user_id INT AS (data ->> '$.user_id') STORED;CREATE INDEX idx_orders_user_id ON orders(user_id);- 之后JOIN就写
ON orders.user_id = users.id，走索引，不解析JSON - 注意：虚拟列必须
STORED才能建索引；GENERATED ALWAYS AS是必须写的，不能省
跨库或NULL值处理要格外小心
JSON字段里路径不存在时，->>返回NULL，JOIN会自动跳过这些行（因为NULL = anything恒为FALSE）。如果业务上需要保留左表记录，得用LEFT JOIN，但得意识到右表匹配字段也会是NULL。
更麻烦的是PostgreSQL或SQL Server语法不兼容：->>是MySQL特有；PostgreSQL用->>但返回TEXT，SQL Server得用JSON_VALUE()且需配合ISJSON()过滤脏数据——跨数据库迁移时这里最容易漏掉校验逻辑。
