【昌哥IT课堂】MySQL8.3 EXPLAIN中的新JSON格式(译)

MySQL提供了两个用于分析查询计划的强大工具：EXPLAIN和EXPLAIN ANALYZE。EXPLAIN显示优化器选择的执行计划，并在执行之前停止，而EXPLAIN ANALYZE实际执行查询并收集有关每个操作的处理时间和返回行数的统计信息。输出格式可以是表格形式（TRADITIONAL）、树形结构或JSON。前两种格式适用于人类阅读，而JSON格式主要面向机器，同时也易于人类阅读。JSON格式应该是自动化查询分析的理想格式，但自从我们转换为基于迭代器的执行计划后，它未能正确表示计划结构。这使得使用JSON格式进行EXPLAIN ANALYZE变得不可能，因为EXPLAIN ANALYZE直接与计划的迭代器结构相关联。

在MySQL 8.3社区版中，我们引入了一个新的JSON格式用于EXPLAIN和EXPLAIN ANALYZE，同时引入了系统变量"explain_json_format_version={1,2}"来在不同格式之间切换。新的JSON格式反映了迭代器的构建方式，直接匹配TREE格式。JSON格式中的每个对象对应TREE格式中的一行，但JSON格式以机器可读的格式包含更多信息，可以通过例如EXPLAIN INTO或客户端应用程序访问。这在支持新JSON格式的EXPLAIN ANALYZE以及最近添加的EXPLAIN INTO和EXPLAIN FOR SCHEMA功能中尤为有用。因此，EXPLAIN树中的所有值都可以通过JSON格式访问并进行程序化分析。

如何使用新的JSON格式
谈论新功能时不能没有示例，所以让我们看一个简单的SELECT查询：
mysql> EXPLAIN FORMAT=TREE SELECT name, quantity FROM orders JOIN items i ON item_id = i.id WHERE quantity > 1000;
-> Nested loop inner join (cost=49828 rows=76470)
-> Filter: ((orders.quantity > 1000) and (orders.item_id is not null)) (cost=23063 rows=76470)
-> Table scan on orders (cost=23063 rows=229432)
-> Single-row index lookup on i using PRIMARY (id=orders.item_id) (cost=0.25 rows=1)
TREE格式虽然对人类读者来说紧凑且易于阅读和理解，但需要手动解析才能在代码中进行分析。使用EXPLAIN FORMAT=JSON，您可以获得一个JSON对象，可以在您喜欢的编程语言中的客户端端处理，或者在MySQL中使用EXPLAIN INTO进行处理。这种JSON格式是在MySQL 5.6中引入的，反映了当时的计划结构。随着转换为基于迭代器的计划，这种旧的JSON EXPLAIN格式不再代表内部计划结构。
# Old JSON EXPLAIN format, default
mysql> SET explain_json_format_version=1;
mysql> EXPLAIN FORMAT=JSON SELECT name, quantity FROM orders JOIN items i ON item_id = i.id WHERE quantity > 1000\G
{
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "49827.84"
    },
    "nested_loop": [
      {
        "table": {
          "table_name": "orders",
          "access_type": "ALL",
          "possible_keys": [
            "fk_item_id"
          ],
          "rows_examined_per_scan": 229432,
          "rows_produced_per_join": 76469,
          "filtered": "33.33",
          "cost_info": {
            "read_cost": "15416.48",
            "eval_cost": "7646.97",
            "prefix_cost": "23063.45",
            "data_read_per_join": "1M"
          },
          "used_columns": [
            "item_id",
            "quantity"
          ],
          "attached_condition": "((`customer`.`orders`.`quantity` > 1000) and (`customer`.`orders`.`item_id` is not null))"
        }
      },
      {
        "table": {
          "table_name": "i",
          "access_type": "eq_ref",
          "possible_keys": [
            "PRIMARY"
          ],
          "key": "PRIMARY",
          "used_key_parts": [
            "id"
          ],
          "key_length": "4",
          "ref": [
            "customer.orders.item_id"
          ],
          "rows_examined_per_scan": 1,
          "rows_produced_per_join": 76469,
          "filtered": "100.00",
          "cost_info": {
            "read_cost": "19117.42",
            "eval_cost": "7646.97",
            "prefix_cost": "49827.84",
            "data_read_per_join": "19M"
          },
          "used_columns": [
            "id",
            "name"
          ]
        }
      }
    ]
  }
}

正如我们从这个例子中看到的，实际执行计划中的迭代器结构在TREE格式中显示，但在旧的JSON格式中并没有反映出来。在对订单表进行表扫描时，过滤器迭代器更像是一个脚注，而关于行和连接成本的所有信息都在两个表对象下。虽然这些值是正确的，但结构是错误的，这使得使用这些信息来优化你的查询变得更加困难。

随着HeatWave MySQL中新MySQL超图优化器的开发，引入了一种新的JSON EXPLAIN格式，因为旧格式与遗留的规划过程或由优化器创建的最终计划没有关联。使用超图优化器并执行EXPLAIN FORMAT=JSON将始终产生这种新的JSON格式。如果您使用的是旧优化器并且运行的是MySQL 8.3或更新版本，可以通过将系统变量"explain_json_format_version"设置为2来访问新的JSON格式。

# New JSON EXPLAIN format
mysql> SET explain_json_format_version=2;
mysql> EXPLAIN FORMAT=JSON SELECT name, quantity FROM orders JOIN items i ON item_id = i.id WHERE quantity > 1000;
{
  "query": "/* select#1 */ select `i`.`name` AS `name`,`customer`.`orders`.`quantity` AS `quantity` from `customer`.`orders` join `customer`.`items` `i` where ((`i`.`id` = `customer`.`orders`.`item_id`) and (`customer`.`orders`.`quantity` > 1000))",
  "inputs": [
    {
      "inputs": [
        {
          "operation": "Table scan on orders",
          "table_name": "orders",
          "access_type": "table",
          "schema_name": "customer",
          "used_columns": [
            "item_id",
            "quantity"
          ],
          "estimated_rows": 229432,
          "estimated_total_cost": 23063.45
        }
      ],
      "condition": "((orders.quantity > 1000) and (orders.item_id is not null))",
      "operation": "Filter: ((orders.quantity > 1000) and (orders.item_id is not null))",
      "access_type": "filter",
      "estimated_rows": 76469.68433094025,
      "estimated_total_cost": 23063.45
    },
    {
      "alias": "i",
      "covering": false,
      "operation": "Single-row index lookup on i using PRIMARY (id = orders.item_id)",
      "index_name": "PRIMARY",
      "table_name": "items",
      "access_type": "index",
      "schema_name": "customer",
      "used_columns": [
        "id",
        "name"
      ],
      "estimated_rows": 1,
      "lookup_condition": "id = orders.item_id",
      "index_access_type": "index_lookup",
      "estimated_total_cost": 0.25000130770776513
    }
  ],
  "join_type": "inner join",
  "operation": "Nested loop inner join",
  "access_type": "join",
  "estimated_rows": 76469.68433094025,
  "join_algorithm": "nested_loop",
  "estimated_total_cost": 49827.83951582908
}

我们不会详细介绍新JSON格式中的每个字段，因为它们中的大多数与旧格式相同或只是重命名的版本，或者是相当直观的，但我将提及其中的几个。

如前所述，新的JSON格式与TREE格式直接对应。TREE格式中的顶级迭代器是JSON格式中的顶级对象，而子迭代器可以在JSON对象的“inputs”字段中找到。要将每个迭代器映射到相关的JSON对象，您可以查看JSON中的“operation”字段，这就是在TREE格式中打印的内容。

在旧的JSON格式中存在但现在行为略有变化的字段是“table_name”。在旧格式中，“table_name”实际上是表的别名，而不是底层表的名称。这在新格式中已经改变，其中“table_name”现在是基础表名，并在表有别名时向表访问迭代器添加了新的“alias”字段。别名仍然是在表访问的父迭代器中引用的内容。

使用新的JSON格式与EXPLAIN ANALYZE

新JSON格式的另一个实用特性是，虽然旧的JSON格式不适合显示EXPLAIN ANALYZE的输出，但由于新格式基于与TREE格式相同的迭代器结构，我们现在可以在JSON格式中获得EXPLAIN ANALYZE的输出。这允许对执行时间进行程序化分析，因为EXPLAIN ANALYZE FORMAT=JSON包含多个字段，这些字段包含了以前需要从TREE格式手动解析的信息。
让我们看看我们之前查询的EXPLAIN ANALYZE：
mysql> EXPLAIN ANALYZE FORMAT=TREE SELECT name, quantity FROM orders JOIN items i ON item_id = i.id WHERE quantity > 1000\G
-> Nested loop inner join (cost=49828 rows=76470) (actual time=1.95..5182 rows=227103 loops=1)
-> Filter: ((orders.quantity > 1000) and (orders.item_id is not null)) (cost=23063 rows=76470) (actual time=1.82..1271 rows=227103 loops=1)
-> Table scan on orders (cost=23063 rows=229432) (actual time=1.76..1135 rows=229376 loops=1)
-> Single-row index lookup on i using PRIMARY (id=orders.item_id) (cost=0.25 rows=1) (actual time=0.0164..0.0164 rows=1 loops=227103)

这里是同样的计划，使用FORMAT=JSON：
mysql> SET explain_json_format_version=2;
mysql> EXPLAIN ANALYZE FORMAT=JSON SELECT name, quantity FROM orders JOIN items i ON item_id = i.id WHERE quantity > 1000\G
{
"query": "/* select#1 */ select `i`.`name` AS `name`,`customer`.`orders`.`quantity` AS `quantity` from `customer`.`orders` join `customer`.`items` `i` where ((`i`.`id` = `customer`.`orders`.`item_id`) and (`customer`.`orders`.`quantity` > 1000))",
"inputs": [
{
"inputs": [
{
"operation": "Table scan on orders",
"table_name": "orders",
"access_type": "table",
"actual_rows": 229376.0,
"schema_name": "customer",
"actual_loops": 1,
"used_columns": [
"item_id",
"quantity"
],
"estimated_rows": 229432.0,
"actual_last_row_ms": 1123.953248,
"actual_first_row_ms": 1.868662,
"estimated_total_cost": 23063.45
}
],
"condition": "((orders.quantity > 1000) and (orders.item_id is not null))",
"operation": "Filter: ((orders.quantity > 1000) and (orders.item_id is not null))",
"access_type": "filter",
"actual_rows": 227103.0,
"actual_loops": 1,
"estimated_rows": 76469.68433094025,
"actual_last_row_ms": 1252.748685,
"actual_first_row_ms": 1.92276,
"estimated_total_cost": 23063.45
},
{
"alias": "i",
"covering": false,
"operation": "Single-row index lookup on i using PRIMARY (id = orders.item_id)",
"index_name": "PRIMARY",
"table_name": "items",
"access_type": "index",
"actual_rows": 1.0,
"schema_name": "customer",
"actual_loops": 227103,
"used_columns": [
"id",
"name"
],
"estimated_rows": 1.0,
"lookup_condition": "id = orders.item_id",
"index_access_type": "index_lookup",
"actual_last_row_ms": 0.016049919261304342,
"actual_first_row_ms": 0.015992197227689638,
"estimated_total_cost": 0.25000130770776513
}
],
"join_type": "inner join",
"operation": "Nested loop inner join",
"access_type": "join",
"actual_rows": 227103.0,
"actual_loops": 1,
"estimated_rows": 76469.68433094025,
"join_algorithm": "nested_loop",
"actual_last_row_ms": 5071.693038,
"actual_first_row_ms": 2.071419,
"estimated_total_cost": 49827.83951582908
}
使用EXPLAIN ANALYZE，我们得到了一些以"actual_"开头的额外字段，这些字段包含了关于执行的信息。在TREE格式中，这些信息与迭代器中的执行信息相同，比如"(actual time=<actual_first_row_ms>..<actual_last_row_ms> rows=<actual_rows> loops=<actual_loops>)"。

总结
EXPLAIN和EXPLAIN ANALYZE的新JSON格式首次在MySQL 8.3社区版中引入，现在也可用于所有平台上的MySQL 8.4 LTS和9.x创新版本，包括OCI、AWS和Azure上的HeatWave MySQL。这种新格式允许基于实际执行计划进行详细的查询分析，无论是在本地还是使用EXPLAIN INTO在服务器上。在TREE格式中找到的所有信息都可以使用JSON函数轻松访问，因此您不必手动解析TREE输出。这在EXPLAIN ANALYZE中特别有用，因为在早期版本中它没有JSON格式。新的JSON格式已经被HeatWave Autopilot用于云中的索引建议，也应该有助于您在自己的应用程序中收集额外的洞察。记得将"explain_json_format_version"设置为2，或者在HeatWave MySQL 9.x中使用新的MySQL超图优化器，以享受EXPLAIN和EXPLAIN ANALYZE新JSON格式的好处。

感谢您使用MySQL！

翻译转载:https://blogs.oracle.com/mysql/post/new-json-format-for-explain