はしけむです。
ありがとうございます。


>>「じゃがいも の検索結果 8031件」というような表示
>
> ここが一番苦労する箇所になるでしょうね。

そうなんですよ。レコード数の表示も、頭を悩ませている部分の一つです。

現在、とろうとしている解決策は、検索フレーズとレコード数を対応させた
サマリテーブルを作ってしまうというものです。

そして、サマリテーブルに無い検索フレーズで検索された場合に、
はじめてSELECT COUNT を行い、
サマリテーブルに、その検索フレーズの行を追加するという仕組みに
しようかと考えています。


> LIMIT 0,10 で判定対象がインデックスデータだけなら 10 件目が見つかれば
> そこで終了ですが、LIMIT 8000,10 ならどうなるでしょうか？

これは、「次へ≫」を押していっても、せいぜい20ページ以内の
ユーザがほとんどだろうという前提で進めようと思っています。
なので、LIMIT 200,10 程度が快速に動けば、問題ないです。


> 個人的には色々とごちゃごちゃ捏ね繰り回すくらいなら、
> 1GBぐらいのメモリを積んで MySQL へのメモリ割り当てを増やす方法にも
> 一票投票しておきます。

メモリは、2GB積んでいるので、インデックスは、メモリに乗るサイズに
なるとは思います。
それにしても、１日数十万回の検索が行われる予定なので、クエリの速度を
ぎりぎりまで高めておく必要があり、試行錯誤を行っています。


T.Sasaki wrote:
> 佐々木です。
> 
> 
>>「じゃがいも の検索結果 8031件」というような表示
> 
> 
> ここが一番苦労する箇所になるでしょうね。
> 全件数をカウントするにはインデックス全データに対する判定を完了させる
> 必要があり、FULLTEXT インデックスのサイズが鍵になります。
> もしインデックス領域が全てメモリ上に乗る、またはヒットするデータの
> 範囲がインデックス上のごく一部分なら、はしけむさんのアイデアで
> 上手く行く可能性も出てくるんじゃないかと思います。
> Oracle なんかだと、事前にインデックスやテーブルをメモリ上へ展開して、
> 検索速度を稼ぐチューニングをすることがあります。
> MySQL で出来たかどうか、ちょっと知識不足で分かりませんが・・・。
> 
> 
> 
>>1ページに10件ずつ表示して、「次へ≫」というリンクで、
>>次の10件が見れるようなページを作ろうとしています。
> 
> 
> これも主キーのように１件分のインデックスデータサイズが小さければ
> 楽なんですが、FULLTEXT インデックスみたいに大きいと厳しいような気がします。
> LIMIT 句は実際にレコードを返す段階で処理されますから。
> LIMIT 0,10 で判定対象がインデックスデータだけなら 10 件目が見つかれば
> そこで終了ですが、LIMIT 8000,10 ならどうなるでしょうか？
> 少なくとも LIMIT 0,10 と同じようには行かないと思います。
> 主キーとか Oracle の ROWID (物理的な格納アドレス) みたいなのが相手なら
> 色々な技が使えるでしょうけど・・・。
> 
> 個人的には色々とごちゃごちゃ捏ね繰り回すくらいなら、
> 1GBぐらいのメモリを積んで MySQL へのメモリ割り当てを増やす方法にも
> 一票投票しておきます。