人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

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の検索が非常に遅いです。こんな差が生じるにはどのような原因が考えられるでしょうか?
よろしくお願いいたします。

●質問者: okenji
●カテゴリ:コンピュータ インターネット
✍キーワード:keyword Linux MySQL name SELECT
○ 状態 :終了
└ 回答数 : 2/2件

▽最新の回答へ

1 ● kn1967
●35ポイント

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

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

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

◎質問者からの返答

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

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


2 ● b-wind
●35ポイント

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

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


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

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

◎質問者からの返答

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

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

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ