MySQLの「ORDER BY」に対するインデックス使用について質問です。

50万件程のテーブル「user」と10件程のテーブル「type」があり、
2テーブルを結合したクエリにORDER BYを使うとインデックスを張ってもusing filesortとなってしまいます。

問題のクエリはこちらです。
select * from user,type where user.type_id = type.id order by created_at DESC;
type_id…int型カラム
created_at…datetime型カラム

userテーブルへのインデックスを「created_at」に張り、複合インデックスを「type_id,created_at」に張っています。

これはORDER BYを上の形で使ってはいけないということなのでしょうか?
それとも私のインデックスの張り方やクエリがおかしいのでしょうか?

下記の記事で「自己結合」を行うことも検討しているのですが、
2つのテーブルに対する検索も行いたいため、できればインデックスで解決したいと思っています。
■MySQL の filesort プチテクニック
http://d.hatena.ne.jp/kazuhooku/20081208/1228707040

どうかお力添えをよろしくお願いします。

回答の条件
  • 1人5回まで
  • 13歳以上
  • 登録:2013/11/21 12:19:12
  • 終了:2013/11/28 12:20:04

回答(1件)

id:language_and_engineering No.1

lang_and_engine回答回数170ベストアンサー獲得回数632013/11/22 04:38:03

インデックスの種類によりますが,type_idへの複合インデックスはほとんど意味をなしていないはずです。値が10件では…。
削除しましょう。

http://itpro.nikkeibp.co.jp/article/COLUMN/20070919/282317/
>この例から言えることは、値の種類が少ないカラムにインデックスを付けても効果は得られない、ということです。[性別]のように2種類しかないデータはその典型ですが、[地域]カラムも値の種類は9種類しかなく、効果を得にくいカラムと言えそうです。


次にcreated_atのほうですが,数十万件に達している時点で単独テーブルでもfilesortは避けられないはずです。
DESCでソートするためのカラムを別途用意しておくという手があるので,下記URLをご参考に対処してみてください。
http://d.hatena.ne.jp/bco/20101225/1293282314


よかったら,この対処をする前後でexplainの出力が具体的にどう変化したか,ご報告して下さると嬉しいです。

コメントはまだありません

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

トラックバック

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

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

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