岡田様、

こんばんは。

On 03/09/2009, at 8:35 PM, Takayuki Okada wrote:

> お世話になります。
> 岡田と申します。
>
> 非常に漠然とした質問になり、すみません。
>
> DB2からMySQLへ移行し、性能を測ってみたところ、
> 全件検索が非常に遅くなりました。
>
> explainで確認すると、一応、PKは使用しているようですが、
> 件数が多くなると、やはり遅くなります。
>
> 何かよいチューニング方法はないでしょうか？
> インデックスは条件句が複数となるため、
> それごとに作成したくはないと思ってますので、
> パラメータで改善できればベストです。
> また、アプローチに関してもご教示いただければ、幸いです。
> ＃Enterpriseシルバーなので、チューニングはサポートに
> 聞けないので、本ＭＬに投稿させていただきました。
>
> ちなみに、バージョンは5.1.31で、
> 対象のテーブルはエンジンはInnoDBで作成しております。

Platinum買ってください・・・と言いたい気持ちを抑えて、以下ちょっと 
だけ
チューニングの指針などについて述べてみたいと思います。

要件が全件検索ということなので、この場合EXPLAINはあまり役に 
立たないと思います。
もし、テーブルの全件に対して結果行が極端に少なければ、インデックス 
または
パーティショニングを使った方が良いのは間違い有りませんので、まずは 
インデックスや
パーティショニングによって効率化が出来るかどうかを検討してみてくだ 
さい。

返される結果がテーブルの半数程度というように、あまり絞り込みが行わ 
れない場合は
インデックスは利用しない方がいいでしょう。その場合は次の点に気を配 
ると良いと思います。
・できるだけデータをInnoDBバッファプールにのせる。（100% 
メモリ上にあれば最速です。）
・ファイルシステムまわりをチューニングする。

100%メモリ上にデータが乗ってる状態で、さらにSELECTを速くした 
い場合には、
速いCPU・メモリバスが必要です。

ファイルシステムまわりのチューニングに関しては、ファイルシステムの 
種類によって
チューニングの方法が異なります。InnoDBをext3上で利用す 
る場合、cfqスケジューラと
相性がよくないことが知られていますので、まずはdeadline等に変 
更しましょう。
xfsを利用するという手もあります。Solaris/ZFSの場合には、レ 
コードサイズを16KBに
したり、プリフェッチを無効化したりすると幸せになれます。

I/Oをとことん高速化するのであれば、思い切ってRAWデバイス上で 
利用することも検討してみて下さい。
↓マニュアルです。
http://dev.mysql.com/doc/refman/5.1/en/innodb-raw-devices.html

後は、速いディスクを利用しましょう。MySQLも他のDBと同 
様、ディスクの性能は大事です。
今月号のDB Magazineに

SSDによるRDBMSの高速化を徹底検証！そのアーキテクチャと利用効 
果を探る／松信嘉範

というマニアックな記事が載っているので参考になると思います。

さらに高速化を狙うのであれば、最近リリースされたばかりのMySQL  
5.1.38を利用するという手があります。
このバージョンにはInnoDB Plugin 1.0.4が同梱されており、デ 
フォルトのInnoDBにくらべて
I/O性能が大幅に強化されています。設定方法などについてはこちらを参 
照してください。
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-38.html

効果のほどは↓のページなどをご覧下さい。
http://opendatabaselife.blogspot.com/2009/08/innodb-plugin-104-innodb.html

※上記の記事ではグループコミットによる更新性能について語られていま 
すが、I/Oスレッドが
　多重化されているのでReadも速くなります。（速いディスクの性 
能を活かせるようになります。）

ただし、InnoDB Plugin 1.0.4はまだ正式版ではなく、β扱いなの 
でその点はご了承頂いた
上でご利用下さい。

では。
--
Mikiya Okuno, MySQL Support Engineer
Sun Microsystems KK, Tokyo, Japan
http://www-jp.mysql.com/