JSON_TABLE必须位于顶层FROM或JOIN中，不可嵌套于子查询FROM内；处理多层嵌套需两层JSON_TABLE配合JOIN，且过滤条件应置于ON子句以避免丢失主记录。
JSON_TABLE 不能直接嵌套在子查询 FROM 子句里？
MySQL 不允许把 JSON_TABLE 当作普通表名写在子查询的 FROM 里，比如 SELECT * FROM (SELECT ... FROM JSON_TABLE(...)) t 这种写法会报错 ERROR 1248: Every derived table must have its own alias —— 不是因为语法错，而是 MySQL 解析器对 JSON_TABLE 的上下文支持有限，它必须出现在顶层 FROM 或显式 JOIN 中。
真正能用的方式是：把 JSON_TABLE 放在主查询的 FROM 或 JOIN 位置，再用外层查询包裹逻辑。如果非要“嵌套提取”，得靠两层 JSON_TABLE 配合 JOIN 实现，而不是子查询套子查询。
-
JSON_TABLE必须紧跟在表名或别名之后，不能作为子查询返回的“虚拟表”被再次引用 - 想对
JSON_TABLE的结果再加工（比如过滤、聚合），只能在外层SELECT中做，不能把它塞进另一个FROM ( ... ) - 若原始 JSON 是多层嵌套对象 + 数组（例如
{"user": {"id": 1, "orders": [{"amt": 100}, {"amt": 200}]}}），需先用一层JSON_TABLE提取user，再JOIN第二层JSON_TABLE处理orders数组
如何用 JOIN 连接两层 JSON_TABLE 提取嵌套数组？
典型场景：一个订单主记录含用户信息和订单明细数组，你想展开成“每个明细一行”，同时带上用户字段。不能只靠一层 JSON_TABLE，因为路径 '$.user.orders[*]' 只能拿到数组元素，拿不到 $.user.id 这类同级字段。
正确做法是：第一层 JSON_TABLE 提取根对象（如 '$'），把 user 对象作为一列；第二层用 JSON_TABLE 基于该列再次解析其内部数组。
SELECT
u.id AS user_id,
u.name AS user_name,
o.amt AS order_amt
FROM orders o_main
JOIN JSON_TABLE(
o_main.data,
'$' COLUMNS (
id INT PATH '$.user.id',
name VARCHAR(50) PATH '$.user.name',
orders JSON PATH '$.user.orders'
)
) AS u ON TRUE
JOIN JSON_TABLE(
u.orders,
'$[*]' COLUMNS (
amt DECIMAL(10,2) PATH '$.amt'
)
) AS o ON TRUE;
- 第一层
JSON_TABLE路径用'$'，把整个 JSON 当作根，从中抽user.id、user.name和user.orders（保留为 JSON 类型） - 第二层
JSON_TABLE输入是上一层的u.orders列，路径用'$[*]'遍历数组，每项生成一行 -
ON TRUE是必需的连接条件，因为JSON_TABLE不基于键匹配，只是“横向展开”
WHERE 条件里怎么安全地用 JSON_TABLE 展开后的字段？
很多人试图在 WHERE 里直接写 o.amt > 100，但要注意：如果原始 JSON 中 orders 是空数组或 NULL，JSON_TABLE(u.orders, '$[*] ...') 会返回零行，导致整条记录从结果中消失 —— 这不是 bug，是 JOIN 的语义决定的。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
若你希望主记录保留（即使没订单明细），得改用 LEFT JOIN，并把过滤条件移到 ON 子句里，而不是 WHERE：
LEFT JOIN JSON_TABLE(
u.orders,
'$[*]' COLUMNS (
amt DECIMAL(10,2) PATH '$.amt'
)
) AS o ON o.amt > 100
- 用
LEFT JOIN保证主记录不丢 - 把
o.amt > 100放在ON里，否则WHERE o.amt > 100会把o为NULL的行全滤掉 -
JSON_TABLE对无效 JSON 返回空集，不会报错，但会导致关联丢失 —— 建议前置加JSON_VALID(o_main.data)过滤
性能关键点：别让 JSON_TABLE 成为全表扫描黑洞
JSON_TABLE 本身不走索引，每次执行都会解析整列 JSON 字符串。如果表有百万行，又没前置过滤，哪怕只取 10 行，也可能先解析全部 JSON 再 LIMIT —— 因为 MySQL 优化器无法下推 LIMIT 到 JSON_TABLE 展开前。
真正有效的优化只有两个方向：
- 在
JOIN JSON_TABLE前，用普通字段（如status = 'active'）或生成列索引（如v_user_id）大幅缩小输入行数 - 避免在大表上直接
SELECT ... FROM big_table, JSON_TABLE(...)，先用子查询或 CTE 把目标主键拎出来，再关联展开 - 如果只是偶尔查，且 JSON 结构固定，长期方案仍是建生成列 + 索引，而不是依赖
JSON_TABLE实时解析
最易被忽略的是：JSON 字段长度越大、嵌套越深、数组元素越多，JSON_TABLE 单行解析耗时就呈非线性增长 —— 测试时用几条数据没问题，上线后数据量翻十倍，响应可能从 50ms 涨到 2s。
