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

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

ただいまの
回答率

89.70%

mysqlでのSQL速度の改善について

解決済

回答 3

投稿 編集

  • 評価
  • クリップ 2
  • VIEW 2,099

dsk777

score 17

mysqlでのSQLについてアドバイスをいただきたく、投稿しました。

以下のようなDBレコードが、現在、120,000件程存在します。

id this_key ref_key created_at
1  AAA  2017-07-21
2  BBB  ZZZ,AAA  2017-07-22
3  CCC  AAA  2017-07-23
4  DDD  BBB  2017-07-24

以下、クリエイト文です。

create table (
    id            BIGINT        AUTO_INCREMENT,
    this_key    TEXT,
    ref_key        TEXT,
    created_at    datetime,
    INDEX( id, this_key(150),  ref_key(150), created_at )
)

ref_key に含まれる文字列を this_key で参照し、レコードの相関表を出力する次のようなSQLを流しました。

select A.id, min(B.id) 
from hoge as A left join hoge as B on ( B.ref_key like concat( '%', A.this_key , '%' ) and B.created_at >= A.created_at )
group by A.id
order by A.id;

想定される出力結果は次のとおりです。

A.id B.id
1  2
2  4
3  NULL
4  NULL

が、レコード件数増加にともない、このSQL文が処理が終わらず、戻ってこなくなりました。
(数時間たっても反応が無い状態です)

レコード数が1000件前後だったころは、問題もなく処理できていたのですが、
増加に伴いレスポンスが著しく低下してきている現状です。

ref_key に対する like演算子の影響で indexは機能していない状態なのですが、
速度の改善がみられるようなSQL文の記述方法、別のアプローチなどあれば、アドバイスいただけないでしょうか?

どうぞ、よろしくお願い申し上げます。

  • 気になる質問をクリップする

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

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

    クリップを取り消します

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

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

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

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

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

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

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

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

    質問の評価を下げる

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

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

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

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

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

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

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

    詳細な説明はこちら

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

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

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

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

  • Kosuke_Shibuya

    2017/07/25 16:18

    インデックス情報がわかるように、CREATE TABLE で提示してください。

    キャンセル

回答 3

checkベストアンサー

+9

1つのカラムに複数の情報を入れていますね。これはリレーショナルモデルデータベースで最もやってはいけない手法のひとつです。DBの操作が非常に煩雑になる上にパフォーマンスは出ないし、データの整合が容易に起きてしてしまいます。

これを解決するには、this_key と ref_key の関係を表した 交差テーブル を作ることです。内容は下記のような感じです:

 this_key   ref_key 
 BBB        ZZZ     
 BBB        AAA     
 CCC        AAA     
 DDD        BBB     

こうしたデータベース設計のやっていけない事とその解決法をあつめた「SQLアンチパターン」という鉄板本があります。同著では今あなたが陥っている問題を Jaywalking(信号無視) というタイトルで紹介しています。すばらしい本ですので、ぜひ買って読んでみてください。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2017/07/25 16:45

    なるほどです。勉強になりました。確かにこのアプローチで実現できそうです。書籍も買わせていただきました。

    キャンセル

  • 2017/07/25 22:59

    交差テーブルを作成することで5分ほど処理が完了するようになりました。
    ありがとうございました。

    キャンセル

+2

this_keyとref_keyがどうリンクしているのかよくわかりません。
普通に正規化してはいけないのでしょうか?
ちなみに前方後方一致「%文字%」はインデックスが効かないので遅いはずです

 問題点

もともとテーブルの定義もおかしいです。

(1)ref_keyの重複にたいしてcreate_atが同じ日が存在した場合
どちらのidを取っていいかわかりません

id this_key ref_key created_at
1 AAA 2017-07-21
2 BBB ZZZ,AAA 2017-07-22
3 CCC AAA 2017-07-23
4 DDD BBB 2017-07-24
5 EEE AAA 2017-07-22

(2)this_keyに重複がないという保証がありません
idはauto_incrementとのことなのできっとユニークなのでしょう

id this_key ref_key created_at
1 AAA 2017-07-21
2 BBB ZZZ,AAA 2017-07-22
3 CCC AAA 2017-07-23
4 DDD BBB 2017-07-24
2 AAA 2017-07-25

投稿

編集

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2017/07/25 16:24

    ありがとうございます。
    正規化というのは、this_keyとref_keyが完全に一致するように加工する?というイメージでしょうか?

    このテーブル、実際のデータは、メールヘッダーのIDとReferencesがそれぞれthis_keyとref_keyに格納されています。
    その為、Referencesの性質上、ref_keyの内容は性質上、これまでのメールの履歴(IDが羅列されたもの)となっており、
    部分一致を使っての検索をおこなっている次第です。

    おっしゃるとおり、完全一致ですとINDEXも効き、速度も大幅に改善するのが確認は取れましたが、
    データとしての整合性が取れていませんでした。

    キャンセル

0

like検索してる時点で手筋が限られててしまうのですが...。
方針としてはおそらくご理解していると思いますが、
0.hogeを正規化してもつ
のがベストです。これが無理な場合、私が思いつくところでは
1.hogeテーブルの更新に追随して変更されるようなindex付テーブルをつくる(Oracleのマテリアライズドビュー)
2.全文検索+FullTextつかう。
とかでしょうか(hogeテーブルの更新頻度とリアルタイム性要求で最適解は変わってくると思いますが)?
1はよくトリガーつかった方法が紹介されていますが、多分若干のラグがあるんじゃないかと思います。
(トランザクションはれば確実にatomicにできますが)
2は割とクセの有る動きをするので使いにくい代物ですが、質問の内容では問題ない可能性もあります。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2017/07/25 23:01

    ありがとうございます。
    無事、別表を一旦作成し、indexを貼ることで速度改善を実現することができました。

    キャンセル

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

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