御意。

# まずはざっくり、(パフォーマンスモニタ等で？)メモリ使用量の確認から？

レス有難うございます。

＞みけさん
Don't Cache Resultを指定してみましたが、期待した効果は得られませんでした。
リードオンリーにしてforward-onlyも指定してみましたが、やはり駄目でした。

＞Banさん
タスクマネージャーで見ている限りではmysqld-nt.exeのメモリ使用量は一定量からふえる
気配が無いので取っては捨てを繰り返しているかもしれませんね。
いずれにしても手詰まり状態でしたので試してみます。

すいません、みけさんの方法でメモリの消費は抑えられました。
肝心の所を書き換えていなかったのでちゃんと動いていませんでした。
とりあえず、実際の出力に掛かる時間も確認しつつ、
調査を続けて見て、また結果を書き込みますね。

うーん
850万件のデータを１つのデータベースで検索するのはやはり時間が掛かると思います。
LANで繋がっているのであれば2つ以上に分散させることは出来ないのでしょうか。
使用頻度の高いデータを選んで新しいサーバに移動するとか出来ないですか？

>850万件のデータを１つのデータベースで検索するのはやはり時間が掛かると思います。
>LANで繋がっているのであれば2つ以上に分散させることは出来ないのでしょうか。
>使用頻度の高いデータを選んで新しいサーバに移動するとか出来ないですか？

実はサーバーもクライアントも同一マシンだったりします。
やっている事はとある製品に使うデータの加工だったりするんですが、
二つもマシンを用意してやるような作業でもないので単一マシンでやっているんです。
なので、サーバーを分割するような事は多分無いと思います。
バッチ処理ですのでリアルタイム性は求めませんが、三日も掛かるのはあんまりでは
と言う話で私自身もそう思ったので色々と手を考えていたのです。

その後の実験でみけさんの方法でもBanさんの方法でも1.7日くらいには
処理時間を縮められそうです。
最初の状況では下手をすると三日以上掛かりそうだったのでかなり短縮できたのでは
と考えています。
とは言え、実際に流している最中ですので最終的にどのくらい掛かるのかは
最後まで流してみないと断言できませんね。
実際に処理が終わってから実測値ついてはお知らせしようと思います。
解決のチェックはそのときに付ける事にします。

最終的な実測が出来ましたので報告して終わりにしたいと思います。

結局、Banさんから提案があったSELECT文で絞り込む事により
一回のヒット件数を抑える事で全体の処理時間を短縮する事ができました。
最終的には3日以上掛かっていた処理が1.6日程度で終わるようになりました。
Banさんの指摘にあったようにMySQL内で管理している結果の総数が多すぎて
処理時間が余計に掛かっていたのではないかと思います。

たくさんの助言有難うございました。