遠藤様
ミヤタ様

ご返信、ありがとうございます。
お二方のご指摘どおり、提示する情報が少なすぎますよね。

一般論として、同じような体験をされ、何かしらの対策を実施した方が
いらっしゃれば参考にしたいな。という軽い気持ちで投稿してしまいました。
反省いたします。

現在、当方のタスクから離れてしまったこともありますが、
少しこちらで整理したうえで、再度、お聞きしたいと思います。

大変、失礼いたしました。

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