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

この記事は2014年8月28日に書かれたものです。内容が古い可能性がありますのでご注意ください。


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

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

実行計画の取得

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

EXPLAIN SELECT id, name FROM tr_address_list;

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

24_explain_sample_1

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

項目 概要
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:
    ソートやグループ化する際にテンポラリテーブル(一時テーブル)が必要な場合に表示される。

実際に高速化を行う際は、SELECT文を上記情報を元に書き換え、再度EXPLAINで実行。
また、実際にSELECT文を実行し、実行時間を計測しながらやっても良いかと思います。

次回はSQLの高速化におけるポイントをいくつか紹介したいと思います。

  • このエントリーをはてなブックマークに追加

PAGE TOP