MySQL 8.x 的解釋 JSON 格式是否正常工作？

Question

我一直在嘗試閱讀 MySQL 8.0.30 執行計划，但我無法對它做出正面或反面。

有問題的測試查詢（參見db<>fiddle ）是：

select *
from (
  select t.a from t join u on u.b = t.a and u.b >= 50
) x
left join (
  select v.c from v join w on w.d = v.c and v.c <= 500
) y on y.c <= x.a

首先，我得到了它的“樹格式”，這對我來說很有意義：

-> Left hashwhich join (no condition), extra conditions: (v.c <= t.a) (cost=8.06 rows=40)
    -> Inner hash join (t.a = u.b) (cost=1.30 rows=1)
        -> Table scan on t (cost=0.26 rows=3)
        -> Hash
            -> Filter: (u.b >= 50) (cost=0.65 rows=1)
                -> Table scan on u (cost=0.65 rows=4)
    -> Hash
        -> Filter: ((v.c <= 500) and (w.d = v.c)) (cost=3.81 rows=30)
            -> Inner hash join (no condition) (cost=3.81 rows=30)
                -> Table scan on w (cost=0.13 rows=6)
                -> Hash
                    -> Table scan on v (cost=0.56 rows=5)

然后，我得到了相同查詢的“JSON 格式”：

{
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "6.47"
    },
    "nested_loop": [
      {
        "table": {
          "table_name": "u",
          "access_type": "ALL",
          "rows_examined_per_scan": 4,
          "rows_produced_per_join": 1,
          "filtered": "33.33",
          "cost_info": {
            "read_cost": "0.52",
            "eval_cost": "0.13",
            "prefix_cost": "0.65",
            "data_read_per_join": "10"
          },
          "used_columns": [
            "b"
          ],
          "attached_condition": "(`fiddle`.`u`.`b` >= 50)"
        }
      },
      {
        "table": {
          "table_name": "t",
          "access_type": "ALL",
          "rows_examined_per_scan": 3,
          "rows_produced_per_join": 1,
          "filtered": "33.33",
          "using_join_buffer": "hash join",
          "cost_info": {
            "read_cost": "0.25",
            "eval_cost": "0.13",
            "prefix_cost": "1.30",
            "data_read_per_join": "10"
          },
          "used_columns": [
            "a"
          ],
          "attached_condition": "(`fiddle`.`t`.`a` = `fiddle`.`u`.`b`)"
        }
      },
      {
        "table": {
          "table_name": "v",
          "access_type": "ALL",
          "rows_examined_per_scan": 5,
          "rows_produced_per_join": 6,
          "filtered": "100.00",
          "using_join_buffer": "hash join",
          "cost_info": {
            "read_cost": "0.25",
            "eval_cost": "0.67",
            "prefix_cost": "2.22",
            "data_read_per_join": "53"
          },
          "used_columns": [
            "c"
          ],
          "attached_condition": "<if>(is_not_null_compl(v..w), ((`fiddle`.`v`.`c` <= `fiddle`.`t`.`a`) and (`fiddle`.`v`.`c` <= 500)), true)"
        }
      },
      {
        "table": {
          "table_name": "w",
          "access_type": "ALL",
          "rows_examined_per_scan": 6,
          "rows_produced_per_join": 39,
          "filtered": "100.00",
          "using_join_buffer": "hash join",
          "cost_info": {
            "read_cost": "0.25",
            "eval_cost": "4.00",
            "prefix_cost": "6.47",
            "data_read_per_join": "319"
          },
          "used_columns": [
            "d"
          ],
          "attached_condition": "<if>(is_not_null_compl(v..w), (`fiddle`.`w`.`d` = `fiddle`.`v`.`c`), true)"
        }
      }
    ]
  }
}

即使是同一個查詢，這些計划在結構上看起來也不同。 在第一個中，我可以看到以樹形式鏈接的運算符，而在 JSON 格式中，它們看起來都扁平化在同一級別——在單個“nested_loop”運算符內。

第一種格式（樹）清楚地顯示了兩個執行分支，而第二種格式（JSON）顯示了單個平面執行序列。

簡而言之，誰在說真話，誰在說謊？