# 前のエントリーに加筆するとか言ってまだ書いてないのに次の事書きますが。
「Tritonnの謎」で書いてたソート云々だけど、コメントをもらったので補足しておくと、sen_records_sort()で問題が解決するというのはつまり (1) sennaで全文検索するとすごい数のレコードがひっかかる (2) MySQLでいくらインデックス使おうにも、使えない量なのか、なにかそれを妨げる条件を満たしている (3) 結局ファイルソートになってしまう (4) 遅い。激重。・・・という事が起こっていたのだと思う。
sen_records_sort()を使った時には、自分はSQLとの結合とかよくわかんなかったので自分が使う最大レコード数 * 10くらいで固定してしまった(これくらいあれば大丈夫だろう、という適当な計算の元)。それでもレコード数としてはせいぜい100の単位なので、大したI/Oは発生しない。結果的にファイルソートになってるんだかなんだかようわからんが、ともかくも一瞬で終わるようになった。当たり前だが。
以上、とりあえず補足。
「Tritonnの謎」で書いてたソート云々だけど、コメントをもらったので補足しておくと、sen_records_sort()で問題が解決するというのはつまり (1) sennaで全文検索するとすごい数のレコードがひっかかる (2) MySQLでいくらインデックス使おうにも、使えない量なのか、なにかそれを妨げる条件を満たしている (3) 結局ファイルソートになってしまう (4) 遅い。激重。・・・という事が起こっていたのだと思う。
sen_records_sort()を使った時には、自分はSQLとの結合とかよくわかんなかったので自分が使う最大レコード数 * 10くらいで固定してしまった(これくらいあれば大丈夫だろう、という適当な計算の元)。それでもレコード数としてはせいぜい100の単位なので、大したI/Oは発生しない。結果的にファイルソートになってるんだかなんだかようわからんが、ともかくも一瞬で終わるようになった。当たり前だが。
以上、とりあえず補足。
カテゴリ
開発トラックバック(0)
このブログ記事に対するトラックバックURL: http://mt.endeworks.jp/cgi-bin/mt-tb.cgi/2030


上のクエリだと、条件に合致するすべての行について、MYD 内の行データの読み込みが発生するので、それがボトルネックになっていると思います。
これは MySQL のオプティマイザが WHERE 句内で指定されたカラムが演算に必要だと判断して、ストレージエンジンから読み込もうとするためです。この問題は拙作のパッチで (ry