SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

最新イベントはこちら!

Security Online Day 2025 春の陣(開催予定)

2025年3月18日(火)オンライン開催

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

EnterpriseZine(エンタープライズジン)

EnterpriseZine編集部が最旬ITトピックの深層に迫る。ここでしか読めない、エンタープライズITの最新トピックをお届けします。

『EnterpriseZine Press』

2024年秋号(EnterpriseZine Press 2024 Autumn)特集「生成AI時代に考える“真のDX人材育成”──『スキル策定』『実践』2つの観点で紐解く」

MySQLチューニング虎の巻

MySQLチューニング虎の巻/ソートに関連するトピックとクエリの書き換え

003


 さて、クエリにJOINが絡む場合にはファイルソートが必要になるかをどのように判断すればいいだろう。複雑だと思われるかも知れないが、実は判断基準は至ってシンプルである。MySQLは基本的に次の選択肢しかない。

 駆動表でソートしてからJOINするか、JOINしてから全体をソートするか。

 さらに駆動表のソートでインデックスを利用できるかどうかという選択肢も加わるので、JOINにおいてどこでソートがされるかは、都合3通りのパターンに分けることが出来る。当然ながら駆動表においてインデックス順にソートすることが出来るならばそれが一番効率的であり、駆動表でソートできない場合が最も効率が悪い。以下にそれぞれの場合のEXPLAIN実行結果を紹介しよう。

 まずは駆動表においてインデックスを使ってソートする場合。

mysql> EXPLAIN SELECT * FROM CountryLanguage cl JOIN Country c ON cl.CountryCode = c.code
    -> WHERE cl.CountryCode LIKE 'j%' ORDER BY cl.CountryCode,cl.Language\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: cl
         type: range
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 3
          ref: NULL
         rows: 16
        Extra: Using where
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: c
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 3
          ref: world.cl.CountryCode
         rows: 1
        Extra: 
2 rows in set (0.00 sec)

 次に駆動表でファイルソートする場合。Using filesortが出ている。

mysql> EXPLAIN SELECT * FROM CountryLanguage cl JOIN Country c ON cl.CountryCode = c.code
    -> WHERE cl.CountryCode LIKE 'j%' ORDER BY cl.Percentage\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: cl
         type: range
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 3
          ref: NULL
         rows: 16
        Extra: Using where; Using filesort
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: c
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 3
          ref: world.cl.CountryCode
         rows: 1
        Extra: 
2 rows in set (0.00 sec)

 最後にJOINしてからファイルソートする場合。Using temporary; Using filesortが出ているのがポイントである。

mysql> EXPLAIN SELECT * FROM CountryLanguage cl JOIN Country c ON cl.CountryCode = c.code
    -> WHERE cl.CountryCode LIKE 'j%' ORDER BY c.Name\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: cl
         type: range
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 3
          ref: NULL
         rows: 16
        Extra: Using where; Using temporary; Using filesort
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: c
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 3
          ref: world.cl.CountryCode
         rows: 1
        Extra: 
2 rows in set (0.00 sec)

 本エントリでは複数のテーブルが絡むJOINについてのさらなる解説は割愛するが、興味のある方は筆者が過去に書いた次のブログエントリを参照して頂きたいと思う。

漢(オトコ)のコンピュータ道: Using filesort

 ORDER BY句でソートを行う場合、何が何でもインデックスを使ったほうが良いか?と言われると、筆者はそのように考えていない。ファイルソートになっているクエリをインデックスを使うようにするということは、当然ながら新たにインデックスを追加することになるからだ。インデックスを追加するとデータサイズが大きくなるし、更新の負荷も上昇してしまう。それに、ファイルソートはそこまで遅くはない。ソートするレコード数が十分に小さければ、ファイルソートのままでも構わないと思う。

 問題となるのはORDER BY句がLIMIT句といっしょに用いられる場合であろう。ファイルソートをしてからLIMIT句でレコードを絞り込むと、せっかくソートした結果が無駄になってしまう。特に、膨大なレコード数をテーブルからフェッチし、ソートしてからLIMIT句でほんの少しのレコードに絞り込むというのは、非常に効率が悪い。LIMIT句がある場合、テーブルからインデックス順にレコードをフェッチしているだけであれば、LIMIT句で指定されたレコード数をフェッチし終えた時点でクエリを終了すれば良いので効率的である。

次のページ
GROUP BY

この記事は参考になりましたか?

  • Facebook
  • X
  • Pocket
  • note
MySQLチューニング虎の巻連載記事一覧

もっと読む

この記事の著者

奥野 幹也 (オクノ ミキヤ)

日本オラクル株式会社
MySQL Global Business Unitテクニカルアナリスト

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/3695 2012/02/10 18:27

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング