MySQL 5.7+ 原生支持 JSON_EXTRACT，低版本需用 SUBSTRING_INDEX 或正则硬解析；子查询中直接使用可能因版本不兼容报“FUNCTION JSON_EXTRACT does not exist”，或因未显式转换类型导致“Invalid JSON text”错误。
子查询里直接用 JSON_EXTRACT 会报错？先确认数据库版本和函数支持
MySQL 5.7+ 和 MariaDB 10.2+ 才原生支持 JSON_EXTRACT，低版本用 SUBSTRING_INDEX 或正则硬解析风险极高。PostgreSQL 则要用 -> 或 ->> 操作符，不是函数调用。执行前务必查：SELECT VERSION();，避免在子查询中写对了语法却因版本不兼容直接报 FUNCTION JSON_EXTRACT does not exist。
常见错误现象：子查询返回单列但类型是 JSON，外层再套 JSON_EXTRACT 时提示“Invalid JSON text”——其实是内层结果没转成字符串，MySQL 默认把 JSON 字段当二进制 blob 处理，需显式 CAST(... AS CHAR)。
- MySQL 中，
JSON_EXTRACT(json_col, '$.user.id')在子查询里必须搭配CAST或JSON_UNQUOTE才能用于关联 - PostgreSQL 中，
data->'user'->>'id'返回 text，可直接 join，但注意空值：若data->'user'是 null，则整条表达式为 null，关联会丢失记录 - 别在子查询里用
JSON_CONTAINS做过滤条件后还试图提取字段——它只返回布尔值，不是 JSON 路径访问器
二级关联时 JOIN 子查询 vs LATERAL：选错性能差十倍
想从订单表的 meta JSON 字段里取 coupon_id，再关联优惠券表查折扣率？别写两层嵌套子查询。MySQL 不支持 LATERAL，得用 JOIN (SELECT ...) 形式；而 PostgreSQL 支持 LATERAL JOIN，能天然复用外层行的 JSON 字段，避免重复解析。
示例（PostgreSQL）：
SELECT o.id, c.discount_rate FROM orders o LEFT JOIN LATERAL ( SELECT discount_rate FROM coupons WHERE id = (o.meta->>'coupon_id')::int ) c ON true;这里
o.meta->>'coupon_id' 每行只解析一次；若写成 (SELECT ... FROM coupons WHERE id = (SELECT o.meta->>'coupon_id'))，JSON 解析会执行两次。
- MySQL 替代方案：用
JOIN (SELECT id, JSON_UNQUOTE(JSON_EXTRACT(meta, '$.coupon_id')) AS coupon_id FROM orders)，然后ON coupons.id = t.coupon_id - 千万级数据下，没加
JSON_EXTRACT结果的索引，关联字段无法走索引——MySQL 8.0+ 可建函数索引：CREATE INDEX idx_coupon_id ON orders (JSON_UNQUOTE(JSON_EXTRACT(meta, '$.coupon_id'))); - 别在
ON条件里直接写JSON_EXTRACT(orders.meta, '$.coupon_id') = coupons.id，MySQL 会放弃使用任何索引
JSON_EXTRACT 返回数组时怎么展开成多行？JSON_TABLE 是唯一可靠解法
当 JSON 字段存的是用户标签列表：{"tags": ["vip", "new", "active"]}，想每 tag 一行去关联标签维度表？JSON_EXTRACT 返回的是 JSON 数组字符串，不是结果集。MySQL 8.0+ 必须用 JSON_TABLE；之前版本只能靠递归 CTE 或应用层拆分。
示例（MySQL 8.0+）：
SELECT u.id, jt.tag_name FROM users u JOIN JSON_TABLE( u.profile, '$.tags[*]' COLUMNS(tag_name VARCHAR(20) PATH '$') ) AS jt ON jt.tag_name = tags.name;注意路径写
'$.tags[*]'，不是 '$.tags'——后者返回整个数组，前者才逐项展开。
- PostgreSQL 用
jsonb_array_elements_text(profile->'tags')更简洁，但返回的是 text 列，需 alias 后才能 join -
JSON_TABLE的COLUMNS定义里，PATH '$'表示取当前数组元素本身，别误写成'$.tag_name' - 如果数组嵌套深，如
'$.order.items[*].sku'，确保路径语法正确，否则JSON_TABLE返回空结果且无报错提示
JSON 字段关联 NULL 或空字符串时，为什么关联不上？
最常被忽略的一点：JSON 解析后值可能是 SQL NULL，也可能是字符串 'null' 或空串 ''。比如前端传了 {"user_id": null}，JSON_EXTRACT 返回 SQL NULL；但若传了 {"user_id": ""}，返回的是空字符串，和整型 ID 关联必然失败。
- 统一处理方式：MySQL 用
NULLIF(JSON_UNQUOTE(JSON_EXTRACT(meta, '$.user_id')), '')把空串转成 NULL；PostgreSQL 用NULLIF((meta->>'user_id')::text, '') - 检查原始 JSON 是否含多余空格或换行——
JSON_EXTRACT对格式敏感，'{\n"user_id": 123}'没问题，但'{ "user_id": 123 }'（带空格）也合法；真正出问题的是控制字符，可用HEX()查看异常字节 - 别依赖
COALESCE直接兜底，比如COALESCE(JSON_EXTRACT(...), 0)——0 是无效 ID，关联会引入脏数据
JSON 字段做关联分析，本质是把半结构化数据拉回关系模型，每一步解析、转换、关联都可能隐式改变数据语义。版本、空值、路径语法、索引支持，四个点漏掉任何一个，结果就不可信。
