使用 EXPLAIN FORMAT=JSON INTO 保存计划并交给 JSON 函数读取

如果只想在终端里看一次执行计划，普通的 EXPLAIN 已经够用；但当你需要继续取出访问类型、使用的索引或某个查询块的字段时，表格输出就不够顺手了。MySQL 8.4 可以把 JSON 格式的计划直接写入用户变量，再交给 JSON_EXTRACT()、JSON_UNQUOTE() 等函数读取。

最小写法是把 INTO @变量 放在 FORMAT=JSON 后面：

-- 把 SELECT 的 JSON 执行计划保存到当前会话的用户变量
EXPLAIN FORMAT=JSON INTO @select_plan
SELECT order_id, customer_id
FROM orders
WHERE customer_id = 1001;

这条语句保存的是计划数据，不是查询结果。后续语句仍在同一个 MySQL 会话中执行，才能读取 @select_plan。

背景：为什么要先保存 JSON 计划

EXPLAIN 的 TRADITIONAL 输出适合人工扫一眼，但程序化提取时需要依赖列位置和表格字段。FORMAT=JSON 把计划组织成对象和数组，查询块、表访问、候选索引和代价信息都能通过 JSON path 定位。

保存到变量后，分析语句可以与原来的计划语句分开。例如同一份计划既可以读索引，也可以读访问方式，避免为了取不同字段重复写一遍 EXPLAIN：

旧写法的问题：把计划当普通结果集处理

没有 INTO 时，常见做法是让客户端接收 EXPLAIN FORMAT=JSON 返回的值，再在应用代码里解析。这样做并非错误，但会增加客户端取数、转码和再次传递的环节。若只是临时在 MySQL 内取几个字段，直接使用用户变量更紧凑。

还要注意，INTO 不是把任意格式都变成 JSON 变量的通用后缀。本文讨论的组合是 EXPLAIN FORMAT=JSON INTO；不要把它机械套到默认表格格式或 EXPLAIN ANALYZE 上。

新规则：先保存，再沿 JSON path 读取

保存计划后，使用 JSON path 访问结构。例如计划中的表节点通常位于 $.query_block.table，索引名称可以继续取 key，访问方式可以取 access_type：

-- 先保存计划；示例查询只用于说明计划对象的来源
EXPLAIN FORMAT=JSON INTO @plan
SELECT order_id, customer_id
FROM orders
WHERE customer_id = 1001;

-- 读取计划中的索引名称和访问方式
SELECT
  JSON_EXTRACT(@plan, '$.query_block.table.key') AS used_key,
  JSON_EXTRACT(@plan, '$.query_block.table.access_type') AS access_type;

-- 如果需要普通字符串，再去掉 JSON 字符串外层的引号
SELECT JSON_UNQUOTE(
  JSON_EXTRACT(@plan, '$.query_block.table.access_type')
) AS access_type_text;

JSON_EXTRACT() 返回的是 JSON 值，所以字符串结果可能带 JSON 表示层的引号。需要与普通字符串比较或展示时，再使用 JSON_UNQUOTE()；不要在一开始就把所有结果都当作 SQL 字符串。

代码对比：一次提取多个字段并区分缺失路径

计划结构会随着查询类型变化。简单单表查询可以从 query_block.table 取字段；连接、派生表或更复杂的查询可能出现数组和嵌套查询块。因此提取时应先判断路径是否存在，再决定是否转成文本。

-- 保存一份包含连接条件的 JSON 计划
EXPLAIN FORMAT=JSON INTO @join_plan
SELECT o.order_id, c.customer_name
FROM orders AS o
JOIN customers AS c ON c.customer_id = o.customer_id
WHERE o.customer_id = 1001;

-- 读取 JSON 节点是否存在；缺失时不要把 NULL 当成索引名
SELECT
  JSON_CONTAINS_PATH(@join_plan, 'one', '$.query_block') AS has_query_block,
  JSON_CONTAINS_PATH(@join_plan, 'one', '$.query_block.table') AS has_table_node,
  JSON_TYPE(JSON_EXTRACT(@join_plan, '$.query_block')) AS query_block_type;

-- 把计划原样输出，便于继续选择正确的 JSON path
SELECT @join_plan AS plan_json;

这里的 JSON_CONTAINS_PATH() 只是在计划对象内判断路径是否存在，不代表它验证了索引是否合理。路径存在后，仍应根据当前语句的计划结构选择字段。

兼容注意：哪些语句可以使用，变量又在哪里有效

MySQL 8.4 手册把 INTO 示例放在 EXPLAIN FORMAT=JSON 下，并说明它可用于可解释的 SELECT、TABLE、INSERT、UPDATE、DELETE 和 REPLACE 语句。对写操作，EXPLAIN 仍然是查看计划，不会因为保存到变量就执行原来的修改。

-- UPDATE 也可以保存计划，但这里只分析，不修改表数据
EXPLAIN FORMAT=JSON INTO @update_plan
UPDATE orders
SET status = 'paid'
WHERE order_id = 1001;

-- DELETE 同样只保存计划，不执行删除动作
EXPLAIN FORMAT=JSON INTO @delete_plan
DELETE FROM orders
WHERE order_id = 1001;

-- 用户变量属于当前会话；换字段名保存可避免覆盖上一份计划
SELECT
  JSON_EXTRACT(@update_plan, '$.query_block.table.access_type') AS update_access,
  JSON_EXTRACT(@delete_plan, '$.query_block.table.access_type') AS delete_access;

用户变量以连接会话为边界：连接断开后不能指望下一次连接继续拥有它；同名变量再次执行 INTO 会覆盖旧值。需要跨会话、跨任务保存时，应由外部程序或持久化表接管，而不是把用户变量当成存储。

采用建议：把它当作计划字段提取工具

在 MySQL 8.4 中，推荐把这组语法分成三个明确动作：先用 EXPLAIN FORMAT=JSON INTO @plan 固定一份计划，再用 JSON path 读取需要的节点，最后对缺失路径和 JSON 字符串类型做显式处理。这样既保留了完整计划，也避免客户端为了一个字段重复请求。

常见问题

为什么要写成 FORMAT=JSON INTO，而不是 INTO FORMAT=JSON？

这是该语法的固定顺序。先选择 JSON 输出格式，再指定把结果保存到哪个用户变量。

JSON_EXTRACT 取到的字符串为什么有引号？

因为函数返回的是 JSON 值。需要普通文本时使用 JSON_UNQUOTE()，需要继续按 JSON 处理时保留 JSON 类型。

把计划保存进变量后，能不能跨连接读取？

不能把用户变量当跨连接存储。保存和读取应放在同一会话；跨连接场景请由应用层或持久化存储保存原始 JSON。

一句话总结：EXPLAIN FORMAT=JSON INTO @plan 负责把计划留在当前会话，JSON 函数负责从这份计划里取字段；两者配合的关键不是多写函数，而是保持语法顺序、会话连续和 JSON path 与实际结构一致。