mysql 8.0+ join json字段需先用->>提取并显式类型转换，避免隐式转换和null失效；postgresql优先用->>转text再强转类型，并建函数索引；务必验证json结构、空格、大小写及是否为数组。
MySQL 8.0+ 怎么用 JSON_CONTAINS 或 JSON_EXTRACT 做 JOIN？
直接在 JOIN 条件里对 JSON 字段做等值匹配，绝大多数情况下会失效——因为 JSON 值即使内容相同，二进制表示也可能不同（比如键顺序、空格、引号类型）。必须先提取结构化值再比对。
常见错误写法：ON t1.meta->'$.user_id' = t2.id 看似可行，但实际可能因类型隐式转换失败（比如左边是字符串 "123"，右边是整数 123）或 NULL 传播导致漏数据。
- 用
JSON_EXTRACT(t1.meta, '$.user_id')提取后，结果仍是 JSON 类型，需再用->>（即JSON_UNQUOTE(JSON_EXTRACT(...))）转为字符串 - 若目标字段是数字，建议显式转类型：
CAST(t1.meta->>'$.user_id' AS UNSIGNED) - 注意
JSON_EXTRACT遇到不存在的路径返回NULL，而NULL = anything永远为FALSE，JOIN 会自动过滤掉——这是预期行为，但容易误以为“没关联上”
PostgreSQL 怎么用 -> 和 ->> 关联 JSONB 字段？
PostgreSQL 的 jsonb 类型支持 GIN 索引和高效路径查询，比 MySQL 更适合 JSON 关联。关键区别在于：-> 返回 jsonb，->> 返回 text；JOIN 时优先用 ->> 避免类型不匹配。
- 安全写法：
ON (t1.payload->>'user_id')::BIGINT = t2.id，显式强转确保类型一致 - 如果
user_id在 t1 中可能缺失，加AND t1.payload ? 'user_id'可提前过滤掉不含该键的行，避免 CAST 失败报错 - 性能敏感场景下，在
(payload->>'user_id')上建函数索引：CREATE INDEX idx_user_id ON t1 ((payload->>'user_id'));
JOIN 结果为空？检查这三类 JSON 数据问题
不是语法错，而是数据本身让关联“静默失败”。最常被忽略的是：
- JSON 字段存的是数组而非对象，比如
["123", "456"]，此时->'$.user_id'返回NULL—— 应改用JSON_CONTAINS(t1.meta, '"123"', '$')或展开数组（MySQL 8.0+ 用JSON_TABLE） - 字段含多余空格或不可见字符，
->>提取后字符串首尾有空格，导致=匹配失败 —— 加TRIM()更稳妥：TRIM(t1.meta->>'$.user_id') - 大小写混用，如一边是
"UserId"一边是"user_id"，JSON 路径严格区分大小写，别凭感觉猜键名，先SELECT JSON_KEYS(t1.meta) FROM t1 LIMIT 1看真实结构
为什么别在 JOIN 条件里用 JSON_CONTAINS 做模糊关联？
JSON_CONTAINS（MySQL）或 @>（PostgreSQL）适合判断“是否包含某子结构”，但用于 JOIN 易引发全表扫描，且语义模糊——比如想关联合同 ID，却因 JSON 里有多个 ID 字段而误匹配。
- 例如：
JSON_CONTAINS(t1.data, '{"id": 123}')可能命中{"id": 123, "parent_id": 123}，这不是你想要的“精确外键关联” - 真正需要模糊匹配时，应先用
JSON_EXTRACT定位到具体字段，再用LIKE或正则，而不是依赖容器级函数 - 如果 JSON 结构高度不固定，与其硬撑 JOIN，不如把关键关联字段冗余为普通列（如
user_id_cached），并用触发器或应用层维护一致性
JSON 字段不是不能 JOIN，而是必须把它当作“需要预处理的非标数据”来对待。最易被忽略的点：提取后的值类型、NULL 处理、以及原始 JSON 结构的真实形态——跑一条 SELECT meta, JSON_TYPE(meta), JSON_KEYS(meta) FROM t1 LIMIT 5，比反复调 JOIN 语句更省时间。
