MariaDB　はじめてのMariaDB　【第７回 SQLを分析してみよう】

今回は、初歩的なSQLの実行計画の解析方法について記載します。
一般的にDBのパフォーマンスチューニングを行う際に用いられています。

実行計画の取得

DBからデータを取得する際にSELECT文を使用すると思います。
実行計画を取得するには、調査対象となるSQL文の前に
『EXPLAIN』を書いてあげるだけでOKです。

EXPLAIN SELECT id, name FROM tr_address_list;

上記SQLを実際に実行してみましょう。

上記項目について説明します。
各項目を理解することで、記載されているクエリの問題点や改善点が見えてくるかと思います。

項目	概要
id	サブクエリが発行された際の階層レベルのようなもの。クエリは数値の少ないものから順に評価します。
select_type	クエリの種類。JOINやサブクエリ、UNION、それらの組み合わせ。
table	アクセス対象となるテーブル。
type	結合型。以下に最適順に記載。 systel：1レコードのみで構成されるテーブル。 const：一致レコードが1つのみの状態。そのため、オプティマイザにより定数とみなされる。PRIMARY-KEYやUNIQUE-KEYを利用する。 ※オプティマイザ：DBが効率よく高速に動作するようにする機能 eq_ref：PRIMARY-KEYやUNIQUE-KEYを利用したJOINで 1レコードを検索している状態。理想的なJOIN。 ref：ユニーク(PRIMARY-KEY、UNIQUE-KEY)ではないインデックスを使用した等価検索の状態。 range：インデックスを使用した範囲検索の状態。 index：インデックスを全検索(フルインデックススキャン)している状態。。結構遅い。 ALL：全検索(フルテーブルスキャン)。インデックスが未使用の状態。非常に遅い。基本的にALL、indexが出ている場合はSQLの改善を検討した方が良い。
possible_keys	オプティマイザが利用可能なインデックスキーの候補として挙げたもの。ない場合はNULLで表示される。
key	検索の際にオプティマイザが使用すると決めたキー。ない場合はNULLで表示される。
key_len	検索の際にオプティマイザが使用すると決めたキーの長さ。この長さが短ければ短いほど高速に検索する。 keyがない場合はNULLで表示される。
ref	検索する際の条件において、keyと比較している値またはカラムの種類。定数が設定されている場合はconstと表示される。
rows	対象テーブルから取得するデータ数の推測値。あくまでも推測値であるため、正確な値ではない。
Extra	追加情報。DBがどういった方法でデータ取得を行ったのかについて表示される。同時に複数種類のものが表示されることもある。以下にはクエリの改善が必要と思われるもののみを記載する。 Using filesort： filesort(クイックソート)でソートを行っている。メモリバッファのみではソート処理しきれず、テンポラリファイル(一時ファイル)を作成しソート処理を行っている際に表示される。 Using temporary：ソートやグループ化する際にテンポラリテーブル(一時テーブル)が必要な場合に表示される。