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或更高的版本。
其次，可以顺便检查一下JSON相关功能的完整性（这一步非必须，但能帮你排除一些环境配置问题）：
SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_DATAFILES WHERE FILE_NAME LIKE '%json%';
如何用JSON_TABLE把一行JSON字符串展开成多行关系数据？
核心思路其实很直观：就是把那坨嵌套的JSON数据，当成一张“虚拟表”来查询。你需要做的，就是像定义一张新表一样，显式地告诉数据库：虚拟表的列名是什么、数据类型是什么、数据在JSON里的哪个路径（PATH）上。
实际操作中，最容易栽跟头的地方就是路径写错——比如漏了根符号$，或者误用了双引号。另一个常见坑是数据类型不匹配，导致最终字段值全是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，行本身可能还会插入。- 最重要的一点来了！上面示例中的写法，在逻辑上有个小陷阱。注意看，
COLUMNS里所有PATH的参照点，都是相对于$.events[*]的每个元素的。这意味着，PATH '$.user_id'试图从每个数组元素里找user_id，但user_id实际上是在外层JSON里。所以，上面那个写法是“伪正确”的。
更真实的写法应该是这样（假设raw_logs表本身已经有一个user_id字段，或者我们通过其他方式能拿到外层的值）：
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;
如果user_id只存在于JSON内部，且结构更复杂，那就得考虑使用NESTED PATH进行多级展开，或者先解析外层再关联内层数组。
PostgreSQL或SQL Server用户该用什么替代？
别生搬硬套JSON_TABLE的语法。不同的数据库，有自己更地道的解决方案。
对于PostgreSQL，直接上jsonb_to_recordset配合LATERAL连接，才是正解。假设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，核心函数是OPENJSON，配合WITH子句来定义结构：
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' -- 注意：这里同样无法直接取到外层的user_id
) AS j;
同样需要注意的是，如果user_id是在外层JSON对象里，上面这种写法就行不通。SQL Server里更稳妥的做法，是先用OPENJSON解析外层拿到user_id，再用CROSS APPLY去解析内层的events数组。
性能和数据一致性容易被忽略的点
聊完语法，咱们得谈谈实战中更棘手的两个问题：性能和容错。
首先，JSON_TABLE是在查询运行时进行解析的，它无法利用关系型数据库最擅长的索引加速。想象一下，如果raw_logs表有百万行数据，每次查询都要对每一行的JSON字符串进行全量解析，这个I/O和CPU开销是相当可观的。所以，在上线前，务必用生产环境等效的数据量进行压力测试。
其次，数据一致性方面的容错边界，往往容易被忽略：
- JSON格式非法：比如多了个末尾逗号、用了单引号等。这时，根据你设置的是
ERROR ON ERROR还是NULL ON ERROR，整行会被跳过或者字段变成NULL，但通常不会导致整个事务报错中断，这可能 silently 地丢失数据。 - 路径匹配不到任何元素：比如JSON里根本没有
$.events这个路径。JSON_TABLE会直接返回一个空结果集，导致INSERT语句插入0行。这种静默失败，在排查问题时非常头疼。 - 数值溢出：例如，你定义
INT PATH，但JSON里对应位置的值是"9999999999"（超过了INT范围）。数据库会按照自身的转换规则处理，可能是截断，也可能是变成0，同样不会报错。
因此，在真正投入生产环境时，建议增加一层防御性的校验。例如，可以先使用JSON_VALID(rl.payload)过滤掉格式无效的数据，再用JSON_LENGTH(rl.payload->'events')确认数组非空，最后才将合格的数据送入JSON_TABLE进行处理。这一步预处理，能帮你避免很多意想不到的“坑”。
