質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.00%

MySQLのスロークエリを早くしたい

受付中

回答 4

投稿 編集

  • 評価
  • クリップ 1
  • VIEW 651

hang

score 6

 環境

DB: Amazon Aurora(MySQL 5.6互換)
対象テーブルには1億レコード以上あります。

 やりたいこと

以下のクエリで月毎の「レコード増加数」と「レコード数の累計」を算出しています。
実行結果は変えず、現状4分半→理想1分以内で結果が返ってくるように改善したいです。
SQLが初めてなので、どこがボトルネックになっているのかも解説していただけると助かります。
よろしくお願いいたします。

SELECT
    t1.accum_date,
    t1.count,
    SUM(t2.count) AS accum
FROM (
    SELECT
        DATE_FORMAT(created, '%Y%m') AS accum_date,
        COUNT(*) AS count
    FROM
        table
    GROUP BY accum_date
    ORDER BY accum_date
) AS t1
JOIN (
    SELECT
        DATE_FORMAT(created, '%Y%m') AS accum_date,
        COUNT(*) AS count
    FROM
        table
    GROUP BY accum_date
    ORDER BY accum_date
) AS t2
ON
    t1.accum_date >= t2.accum_date
GROUP BY 1
ORDER BY 1
;
+------------+----------+-----------+
| accum_date | count    | accum     |
+------------+----------+-----------+
...(中略)...
| 201808     | 10000000 |  85000000 |
| 201809     | 15000000 | 100000000 |
| 201810     | 20000000 | 120000000 |
+------------+----------+-----------+
50 rows in set (4 min 37.47 sec)

 追記

EXPLAINの結果です。

+----+-------------+------------+------+---------------+------+---------+------+-----------+----------------------------------------------------+
| id | select_type | table      | type | possible_keys | key  | key_len | ref  | rows      | Extra                                              |
+----+-------------+------------+------+---------------+------+---------+------+-----------+----------------------------------------------------+
|  1 | PRIMARY     | <derived2> | ALL  | NULL          | NULL | NULL    | NULL | 120000000 | Using temporary; Using filesort                    |
|  1 | PRIMARY     | <derived3> | ALL  | NULL          | NULL | NULL    | NULL | 120000000 | Using where; Using join buffer (Block Nested Loop) |
|  3 | DERIVED     | table      | ALL  | NULL          | NULL | NULL    | NULL | 120000000 | Using temporary; Using filesort                    |
|  2 | DERIVED     | table      | ALL  | NULL          | NULL | NULL    | NULL | 120000000 | Using temporary; Using filesort                    |
+----+-------------+------------+------+---------------+------+---------+------+-----------+----------------------------------------------------+
  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • maisumakun

    2018/10/23 15:15

    EXPLAINの結果も確認できますか?

    キャンセル

  • hang

    2018/10/23 15:40

    追記しました。よろしくお願いいたします。

    キャンセル

回答 4

+3

まず集計単位が%Y%mだとわかっているならテーブルに専用カラムを用意して
埋め込んでおくとよいでしょう。(適当なインデックスも貼っておく)

また1億件のデータを毎回集計するのはむだなので
日次処理などで過去データは予め集計しておき、
既存の集計済みデータと当日データの集計結果を加算して処理するようにすれば
おそらく数百倍は早くなると思います。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/10/23 16:22

    回答ありがとうございます。
    カラム変更する権限がないため、今回はこのクエリを早くする方向でお願いいたします><

    キャンセル

  • 2018/10/23 16:28

    テーブルの設計がダメなら何をやっても無駄ですよ
    別のサマリーテーブルが作れないならスピードについては諦めるしかないですね。

    キャンセル

+2

相関サブクエリーでの累計は試されましたか?

SELECT
    accum_date,
    count,
    (select count(*) from table where DATE_FORMAT(created, '%Y%m') <= t1.accum_date) as accum
FROM (
    SELECT
        DATE_FORMAT(created, '%Y%m') AS accum_date,
        COUNT(*) AS count
    FROM table
    GROUP BY DATE_FORMAT(created, '%Y%m')
) AS t1
ORDER BY 1
;


MySQL5.7ならファンクションインデックスもどきで多少は改善されそうですけどね。

改善策としては前月までのデータは集計済みとして保持しておく事が考えられます。
その際には、createdのインデックスがあるのが吉。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/10/23 16:21

    > 相関サブクエリーでの累計は試されましたか?
    試していますが、10分以上結果が返ってこないので相関サブクエリーの方が遅いと判断して良さそうです。

    > 改善策としては前月までのデータは集計済みとして保持しておく事が考えられます。
    > その際には、createdのインデックスがあるのが吉。
    なるほどです。
    そういう権限がないため、今回はこのクエリを早くする方向でお願いいたします><
    (提案してみます!)

    キャンセル

  • 2018/10/23 16:28

    分析関数もWITHも使えないし、SQLで何とかするのは無理ぽい気がします。
    後は、@変数使う位でしょうけど。

    キャンセル

0

経験に乏しいので参考程度の回答ですが。

どこがボトルネックか調べる方法ですが、(クエリに寄りますが)例えばサブクエリだけ走らせることで、どの時点で一番時間がかかっているかにあたりを付けることができるかと。

あと、Orderbyは最後に一度やればいいのでは?時間かかりそうですし。

また、データ件数が多いので、テーブルそのものの設定(インデックス設定したり)を見直すべきかどうかもわかればベターな気がします。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/10/23 15:42

    回答ありがとうございます。
    サブクエリは2分強だったので、2本のサブクエリが処理のほどんどを占めているようです。

    キャンセル

  • 2018/10/23 15:46

    最適化されたりなんだりあると思うので、実際、最終的なクエリにおいてどうかはわかりませんが、参考にはなるのでいいかなと思います。サブクエリのOrderBy外してみたらどうでしょうか。

    キャンセル

  • 2018/10/23 16:25

    > サブクエリのOrderBy外してみたらどうでしょうか。

    ほとんど変わりませんでした(誤差の範囲内かと)。
    ありがとうございます。参考になります!

    キャンセル

  • 2018/10/23 16:30

    あらら、そうでしたか。GroupByなどを外した単純なSelectでやってみて、それぞれ2分かかるなら、絞り込むか(要件にないので無理だとは思いますが)、インデックス貼るかぐらいですね(私が思いつく限界)。単純なSelectで早いようなら、GroupByをJoin後、最後にやるというのも手かもしれません。

    キャンセル

0

質問にCREATE TABLE, CREATE INDEX と実行計画SQL実行計画の疑問解決には「とりあえずEXPLAIN」しよう を提示されては?
実行計画の見かた MySQLのEXPLAINを徹底解説!!

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2018/10/23 15:40

    追記しました。よろしくお願いいたします。

    キャンセル

  • 2018/10/24 11:07

    CREATE TABLE, CREATE INDEX は載せる気がないですか?

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.00%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる