気軽に楽しくプログラムと遊ぶ

自分が興味があってためになるかもって思う情報を提供しています。

MySQL 実行計画(EXPLAIN)

MySQLにおける実行計画の見方について記載します。

EXPLAIN 結果確認

クエリコストをみたい場合

format=jsonをつけてexplainを実行する。

explain format=json 【クエリ】

結果Json

query_costの箇所にコストが表示される

{
  "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "3599.86"
    },
    "nested_loop": [
      {
        "table": {
          "table_name": "s",
          "access_type": "ALL",
          "possible_keys": [
            "PRIMARY"
          ],
          "rows_examined_per_scan": 11309,
          "rows_produced_per_join": 113,
          "filtered": "1.00",
          "cost_info": {
            "read_cost": "2400.18",
            "eval_cost": "22.62",
            "prefix_cost": "2422.80",
            "data_read_per_join": "100K"
          },
          "used_columns": [
            "shop_id",
            "shop_nm",
            "menu_cd"
          ],
          ・
          ・
          ・

通常EXPLAINを実行した場合

以下のような形式で結果が表示

f:id:tamata78:20210521172119p:plain

結果項目

各項目の詳細は以下です。

項目名 結果候補 説明
id - 実行順番。同数字の場合、複数クエリが1クエリで実行
select_type PRIMARY 外部クエリ
DEPENDENT SUBQUERY 相関関係のあるサブクエリ
table - 対象テーブル名
partition - どのパーティションテーブルか
type const pk or uniqueインデックスを使用。最も速い
eq_ref -joinにおいてのconstと同義
ref constでないインデックスを使って等価検索(where k = v)を行った時に使用されるアクセス
range indexを用いた範囲検索
index フルインデックススキャン、インデックス全体をスキャンしているので遅い
ALL フルテーブルスキャン、インデックス未使用。一番遅い
possible_keys - optimizerがテーブルのアクセスに利用可能だと判断したインデックス
key - 実際にoptimizerによって使用されたキー
key_len - 選択されたキーの長さ。長さは短いほうが高速
ref - 検索条件でkeyと比較されている値やカラムの種類
const 定数値
結合相手の検索条件カラム JOIN時
rows - テーブルのfetch行数、見積もり
filtered - テーブル条件によってフィルタ処理される行の推定の割合
Extra - optimizerの戦略。項目多いので省略