MySQL 8.0+中JSON字段不可直接用于JOIN ON条件，必须用CAST(JSON_EXTRACT()或->>)转为确定类型并建函数索引；否则全表扫描，性能极差。
MySQL 8.0+ 中用 JSON_EXTRACT 配合 JOIN 关联 JSON 字段
MySQL 5.7 起支持 JSON 类型，但 JSON 字段不能直接用于 JOIN ON 条件——必须先提取成标量值。常见错误是写成 JOIN ... ON user.profile->'$.org_id' = org.id，这在 MySQL 8.0+ 虽语法通过，但无法走索引，性能极差。
正确做法是显式用 JSON_EXTRACT（或更简洁的 ->> 操作符）转为字符串/数字，并确保目标字段有函数索引：
CREATE INDEX idx_user_org_id ON users ((CAST(profile->>'$.org_id' AS UNSIGNED)));
关联时这样写：
SELECT u.name, o.name AS org_name FROM users u JOIN organizations o ON CAST(u.profile->>'$.org_id' AS UNSIGNED) = o.id;
-
->>自动去引号（返回 TEXT），比->更适合等值匹配 - 必须用
CAST(... AS UNSIGNED)或CAST(... AS CHAR)，否则隐式转换可能导致全表扫描 - 函数索引只在 MySQL 8.0.13+ 支持，且仅对虚拟生成列或表达式索引有效
PostgreSQL 中用 ->> 和 jsonb 的 GIN 索引加速 JOIN
PostgreSQL 的 jsonb 类型原生支持高效路径查询，但直接在 JOIN ON 里写 data->>'org_id' 仍会跳过索引——除非你建了表达式索引。
假设 users.data 是 jsonb，想关联 organizations.id：
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
CREATE INDEX idx_users_org_id ON users ((data->>'org_id')); -- 注意括号，这是表达式索引
然后 JOIN：
SELECT u.name, o.name FROM users u JOIN organizations o ON (u.data->>'org_id')::bigint = o.id;
- 务必用
::bigint或::text显式转换，避免 planner 误判类型兼容性 -
jsonb比json更适合 JOIN 场景，因为前者已解析、支持 GIN 索引、路径查询快 - 如果 JSON 中
org_id可能缺失，加WHERE u.data ? 'org_id'提前过滤，避免 NULL 参与等值匹配
SQL Server 2016+ 用 OPENJSON 展开后 JOIN（不是直接 ON JSON 字段）
SQL Server 不允许在 JOIN 条件中直接引用 JSON 内容，必须先用 OPENJSON 把 JSON 字段“摊平”成行集，再 JOIN。这是最常被误解的一点：不存在类似 MySQL 的 ->> 直接用法。
例如，users.config 存着 {"orgId": 123}，要关联 orgs.id：
SELECT u.name, o.name FROM users u CROSS APPLY OPENJSON(u.config) WITH (orgId INT '$.orgId') j JOIN orgs o ON j.orgId = o.id;
-
CROSS APPLY是关键——它把每行 JSON 解析成临时结果集，才能参与 JOIN -
WITH子句必须声明类型（如INT），否则orgId默认是NVARCHAR(4000)，类型不匹配会导致 JOIN 失败或隐式转换慢 - 若 JSON 结构不固定，
OPENJSON无WITH时返回键值对，需额外WHERE [key] = 'orgId'过滤，性能更差
跨数据库通用陷阱：NULL、类型不一致和索引失效
所有数据库在 JSON JOIN 场景下，最容易被忽略的是三类问题：JSON 字段本身为 NULL、路径取值结果为 NULL、以及看似匹配实则类型不同（比如字符串 "123" vs 数字 123）。
- MySQL：
profile->>'$.org_id'在字段为 NULL 或路径不存在时返回NULL，JOIN 会自动跳过该行——但如果你期望 LEFT JOIN 保留左表，就得补COALESCE(profile->>'$.org_id', '-1') - PostgreSQL：
data->>'org_id'对缺失键返回NULL，而data->'org_id'返回 JSONnull，二者在CAST时行为不同 - SQL Server：
OPENJSON默认忽略缺失键，不会生成对应行，所以如果 JSON 缺少orgId，那行就彻底不出现在 JOIN 结果里
真正麻烦的不是语法怎么写，而是确认 JSON 数据的完整性、一致性，以及每次变更 JSON schema 时，是否同步更新了索引定义和 CAST 类型。
