遠藤と申します。

具体例を示された方が、回答をする側もし易くなると思います。

とてもシンプルなＳＱＬであればなおさらです。

このテーブル構造、このＳＱＬでＤＢ２ならこのくらい、Ｍｙ
ＳＱＬならこれくらい、とご呈示されてはどうでしょうか？

ちなみに、ＤＢ２のエンジンも、ＭｙＳＱＬのエンジンも、同
一スペックのマシンで動いているんですよね？
それとネットワークの構成も同じなんですよね？

例えば、ＤＢ２はローカルで１００万件の中から５０万件取り
出すのにめっちゃ早いけど、９６００ｂｐｓのモデムの先のサー
バから５０万件取り出すのにめっちゃ時間かかるから使えない、
って言われても、そりゃ困るってもんです。
たぶん、そんな事は無いんでしょうけど、そう見えても仕方な
いと思います。

何も比較条件が無いなら、誰も回答は出せないと思います。

もしかしたら、岡田さんが求めている結果が、唯一ＭｙＳＱＬ
で不得意な処理かもしれませんよ？だとしたら、ＭｙＳＱＬに
頼るのは諦めるしか無いでしょう。
それも、これも、具体例を出せば一目瞭然です。

如何でしょうか？

少なくとも、私の経験では１００万件中のデータを引っ張り出
すのに、実用に耐えなかった経験はありません。ただ、それも
これも、「条件次第」ですけど。５０万件絞り出せって言われ
たら、設計から見直してくれって相談します。

Sun, 06 Sep 2009 17:14:16 +0900 に、
Takayuki Okada <okada.takayuki@xxxxxxxxxx> さんは書きました:

> 本件ですが、発行されうるselectの条件句の上位６つほどの
> インデックスを作成しましたが、この影響として、
> 登録＆更新処理が非常に遅くなり、とても対策には使えませんでした。
> 
> CPUがすかすかなので、もっと並列で仕事をさせるような
> ことはできないものでしょうか？
> また、show statusの結果も、いたって、悪い箇所は見当たりません。
> 
> ちなみに、select文には副問い合わせもなく、とても
> シンプルなものです。
> 件数が増えると、とても遅くなります。
> 
> それともMySQLは大量データ処理には向かないのでしょうか？
> といっても、対象のテーブルは、100万件程度ですが…。
> 
> 
> >お世話になります。
> >岡田と申します。
> >
> >非常に漠然とした質問になり、すみません。
> >
> >DB2からMySQLへ移行し、性能を測ってみたところ、
> >全件検索が非常に遅くなりました。
> >
> >explainで確認すると、一応、PKは使用しているようですが、
> >件数が多くなると、やはり遅くなります。
> >
> >何かよいチューニング方法はないでしょうか？
> >インデックスは条件句が複数となるため、
> >それごとに作成したくはないと思ってますので、
> >パラメータで改善できればベストです。
> >また、アプローチに関してもご教示いただければ、幸いです。
> >＃Enterpriseシルバーなので、チューニングはサポートに
> >聞けないので、本ＭＬに投稿させていただきました。
> >
> >ちなみに、バージョンは5.1.31で、
> >対象のテーブルはエンジンはInnoDBで作成しております。
> 
> 

--
えんどう
endo@xxxxxxxxxx,endo@xxxxxxxxxx