JSON_TABLE函数在MySQL 8.0.24及以上版本可用，MariaDB不支持；PostgreSQL用jsonb_to_recordset，SQL Server用OPENJSON；需注意版本验证、路径写法、类型匹配及性能容错问题。
JSON_TABLE函数在MySQL 8.0+中是否可用？
不可用。MySQL 直到 8.0.24 才引入 JSON_TABLE，且仅限于 MySQL（MariaDB 不支持，PostgreSQL 用 jsonb_to_recordset，SQL Server 用 OPENJSON）。如果你执行 SELECT * FROM JSON_TABLE(...) 报错 Unknown function 'JSON_TABLE'，大概率是 MySQL 版本低于 8.0.24 或未启用组件。
验证方式：
SELECT VERSION();并确认输出类似
8.0.24 或更高；再查组件状态：SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_DATAFILES WHERE FILE_NAME LIKE '%json%';（非必须，但可辅助判断 JSON 功能完整性）。
如何用JSON_TABLE把一行JSON字符串展开成多行关系数据？
核心是把嵌套 JSON 当作“虚拟表”来查询，需显式声明列名、类型和路径。常见错误是路径写错（比如漏掉 $ 或误用双引号），或类型不匹配导致字段为 NULL。
典型场景：有一张日志表 raw_logs，其中 payload 是 JSON 字符串：
{"user_id": 101, "events": [{"type":"click","ts":1712345678}, {"type":"submit","ts":1712345699}]} 想把每个 events 元素拆成一行，关联 user_id 插入 user_events 表。
实操写法：
INSERT INTO user_events (user_id, event_type, event_ts)
SELECT jt.user_id, jt.event_type, jt.event_ts
FROM raw_logs rl,
JSON_TABLE(
rl.payload,
'$.events[*]' COLUMNS (
user_id INT PATH '$.user_id' ERROR ON ERROR,
event_type VARCHAR(20) PATH '$.type',
event_ts BIGINT PATH '$.ts'
)
) AS jt;
注意点：
-
$.events[*]是横向展开路径，必须指向数组；若写成$会只取根对象，COLUMNS中的$.user_id就找不到（因不在当前上下文） -
ERROR ON ERROR让解析失败时整行跳过，避免插入NULL；换成NULL ON ERROR则字段填NULL - 所有
PATH都相对于$.events[*]的每个元素，所以user_id实际要从外层 JSON 提取，得用NESTED PATH或先 JOIN 原表字段——上面写法是“伪正确”，真实应改用：SELECT rl.user_id, jt.event_type, jt.event_ts FROM raw_logs rl, JSON_TABLE(rl.payload, '$.events[*]' COLUMNS ( event_type VARCHAR(20) PATH '$.type', event_ts BIGINT PATH '$.ts' )) AS jt;
（前提是raw_logs表本身已有user_id字段；否则需用NESTED PATH多级展开）
PostgreSQL或SQL Server用户该用什么替代？
别硬套 JSON_TABLE。PostgreSQL 应直接用 jsonb_to_recordset + LATERAL，SQL Server 用 OPENJSON 配合 WITH 子句。
PostgreSQL 示例（假设 payload 是 jsonb 类型）：
INSERT INTO user_events (user_id, event_type, event_ts)
SELECT (j.*).user_id, (j.*).type, (j.*).ts
FROM raw_logs rl,
LATERAL jsonb_to_recordset(rl.payload->'events') AS j("type" text, "ts" bigint, "user_id" int);
SQL Server 示例：
INSERT INTO user_events (user_id, event_type, event_ts)
SELECT r.user_id, j.type, j.ts
FROM raw_logs r
CROSS APPLY OPENJSON(r.payload, '$.events')
WITH (
type VARCHAR(20) '$.type',
ts BIGINT '$.ts',
user_id INT '$.user_id' -- 注意：这里无法直接从外层取，需提前解析或改结构
) AS j; 如果 user_id 在外层，SQL Server 更稳妥的做法是先用 OPENJSON 解外层，再 CROSS APPLY 解 events 数组。
性能和数据一致性容易被忽略的点
JSON_TABLE 是运行时解析，无索引加速。如果 raw_logs 有百万行，每次查询都全表解析 JSON，I/O 和 CPU 开销明显。上线前务必在生产等效数据量下压测。
更关键的是容错边界：
- JSON 格式非法（如多末尾逗号、单引号）→ 整行被跳过（
ERROR ON ERROR）或字段为NULL（NULL ON ERROR），但不会报错中断事务 - 路径匹配零个元素（如
$.events不存在）→JSON_TABLE返回空结果集，INSERT 插 0 行，极易被忽略 - 数值溢出（如
INT PATH匹配到"9999999999"）→ 按 MySQL 转换规则截断或变 0，不会报错
真正上线时，建议加一层校验：先用 JSON_VALID(rl.payload) 过滤，再用 JSON_LENGTH(rl.payload->'events') 确认数组非空，最后才进 JSON_TABLE。
