# 前のエントリーに加筆するとか言ってまだ書いてないのに次の事書きますが。

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

コメント(1)

kazuho :

上のクエリだと、条件に合致するすべての行について、MYD 内の行データの読み込みが発生するので、それがボトルネックになっていると思います。

これは MySQL のオプティマイザが WHERE 句内で指定されたカラムが演算に必要だと判断して、ストレージエンジンから読み込もうとするためです。この問題は拙作のパッチで (ry

コメントする

筆者

daisuke - a.k.a. "lestrrat", Perl hacker at Livedoor Inc, Japan Perl Association 代表理事

このブログ記事について

このページは、Dが2008年2月11日 16:00に書いたブログ記事です。

ひとつ前のブログ記事は「オープンソースソフトウェアのコードの進化とリリースに関する考察」です。

次のブログ記事は「Rage Against The Machine」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 4.1