SQLの実行速度について質問です。Mysql+linux です。

テーブルの行数が
t_items: 300万程度
t_keyword2: 5000万件程度
t_items_status: 1万件程度
で、

keywordとitemsテーブルを結合した場合、の実行速度が、

select t_items.Name from t_keyword2, t_items where t_keyword2.P
roductID = t_items.ID limit 10;
0.01秒

select t_items.Name from t_items, t_items_status where t_items_st
atus.ProductID = t_items.ID limit 10;
約45秒

となります。

なお、次のカラムにはインデックスが張ってあります。
ただし、t_items_status,t_keyword2においては各IDには重複があります。
t_items_status.ProductID
t_keyword2.ProductID
t_items.ID

t_keyword2テーブルの方がはるかに行数が多いのに、t_items_statusの検索が非常に遅いです。こんな差が生じるにはどのような原因が考えられるでしょうか?
よろしくお願いいたします。

回答の条件
  • 1人3回まで
  • 登録:2008/09/22 10:13:55
  • 終了:2008/09/22 21:53:06

回答(2件)

id:kn1967 No.1

kn1967回答回数2915ベストアンサー獲得回数3012008/09/22 10:29:59

ポイント35pt

from t_items, t_items_status

ではなく

from t_items_status, t_items

といったように

レコード数の多いほうを主として、少ないほうを従としてみてください。


オプティマイザがどのような実行計画を立てたのかを

EXPLAIN を使って問い合わせてみる事も行ってみてください。

http://dev.mysql.com/doc/refman/4.1/ja/optimiser-issues.html

http://dev.mysql.com/doc/refman/4.1/ja/explain.html

(オプティマイザがどのように実行計画を立てるのかといった

アルゴリズムはマイナーバージョンアップでも変わる事があります)

id:okenji

explainの結果を書かなかったのですが、両者であまり違いを感じませんでした。。。

上の方法は試してみます。ありがとうございます。

2008/09/22 21:26:54
id:b-wind No.2

b-wind回答回数3344ベストアンサー獲得回数4402008/09/22 10:36:16

ポイント35pt

いろいろ考えられるので、まずは各IDの型が一致しているかどうかとそれぞれのクエリのEXPLAIN の結果を出してほしい。

MySQL :: MySQL 5.1 リファレンスマニュアル :: 6.2.1 EXPLAINを使用して、クエリを最適化する


もっとも、そこまで極端な差が出ているのならクエリキャッシュが効いていてたまたまという可能性もあると思うが。

MySQL :: MySQL 4.1 リファレンスマニュアル :: 6.9 MySQL クエリキャッシュ

id:okenji

それぞれのSQLを何度も実行してみているのですが、その場合、キャッシュされているとしたら両者ともされているのではないかと思っています。

マニュアルもっとちゃんと読みます。

2008/09/22 21:28:04
  • id:okenji
    1日経って再度実行してみたところ、同じくらいの速度で実行されました。
    昨日は確かに・・・速度に差があったのですが、このように言うと勘違いのようですが・・・何度も何度も現象を再現させたのですが・・・
    もし何かわかればフォロー投稿します。
    ご回答いただいたお二方、ありがとうございました。
  • id:kn1967
    あくまで推測の域をでませんが
    EXPLAINで違いが無いように見えたということであれば
    昨日は一時的に他の処理とも相まって
    Linuxの共有メモリ、ファイルキャッシュの利用が込み合い
    swap発生しまくりになっていたのではないかと・・・。

    あまりに頻繁に今回のような事が起こるようであれば
    MySQLのパフォーマンスチューニングが必要かもしれません。
  • id:okenji
    なるほど。
    あの後、行数も多いことから、バッチで検索結果を保管する別テーブルを沢山作成して
    対応しました。

    なんというか、「逃げ」なので、構成やプログラムは非常にわかりにくくなりますね。
    一般的にこれくらいのシステム(行数で数百万~数千万行のDBを検索するような)では、
    検索結果をバッチで用意するような、その場しのぎの(?)対応ってされているのだろうか、
    と疑問が生じました。

    何にしてもしばらくはこのまま運用しようと思います。
    ありがとうございました。

  • id:b-wind
    >一般的にこれくらいのシステム(行数で数百万~数千万行のDBを検索するような)では、
    >検索結果をバッチで用意するような、その場しのぎの(?)対応ってされているのだろうか、
    検索条件やサーバースペックにも寄るけどそのぐらいならまだリアルタイムで可能な範囲内だと思う。

    もう1桁増えるとさすがにきついから、そういう対応もありだと思うけど。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません