MySQLのSQL_CALC_FOUND_ROWSが遅い件

SQL_CALC_FOUND_ROWSを使うと70%ぐらいいいとか悪いとか、かのIPA様がおっしゃってました。
http://ossipedia.ipa.go.jp/capacity/EV0603280115/
でもなぜか遅いのです。
インデックスが利用できるwhereであれば、二度SQLを投げた方がいいかと思えるぐらいです。
force indexつけても早くならないです。explainしてindex使ってるようでもそれはresult setにしか使ってないんじゃねって感じです。バージョンアップで改善される気がしますが、とにかく今はSQL_CALC_FOUND_ROWSが遅いです。innodbならwhereなくてcount(*)するときはforce indexつけないと遅いです。innodbでwhereありなら大体index使うので(使ってないならそれ変えないとだめ)早いです。
myisamでwhereなしなら確か爆速。whereありならinnodbぐらい。
じゃーSQL_CALC_FOUND_ROWSが早くなるのはいつか、ってなれば、whereでインデックスをそもそも使っていないようなクエリに対してなら早くなるのではないでしょうか。ipa様もwhere使っていないようですし。
http://ossipedia.ipa.go.jp/capacity/CS0604140045/
そうなるとさすがに二度まともなクエリ投げる(SQL_CALC_FOUND_ROWS使わない)のと、一度のまともなクエリ+取り出しのみ(SQL_CALC_FOUND_ROWSと取り出し)なら後者に軍配かなぁ。
SQL_CALC_FOUND_ROWSの効果については以前から疑ってて、ipaのurlと共にこいつぁーいいぜ、ってページが多かったので信じていました。でも未だに信じています。
ぐぐったらかのMySQL Performance Blogが出てきました。
To SQL_CALC_FOUND_ROWS or not to SQL_CALC_FOUND_ROWS?
http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/
英語あまり読めないけど、気になったのは以下の文。
Here is why our count was much faster – MySQL accessed our table data when calculated result set size even when this was not needed (after the first 5 rows specified in LIMIT clause). With count(*) it used index scan inly which is much faster here.
それが必要じゃないとき(limitでとってくる最初の5行以降)でさえ、かるきゅれいてぃっどりざるとせっとがにアクセスするとかしないとか。
count(*)なら内部でインデックス使うからもっと早いよ!
最初の文がよくわからん。やっぱインデックス使ってないの?

コメントを残す