2009年8月のアーカイブ

注文管理関連のテーブルは、何年もサイトを運営していると何十万件というデータが保存されることになる。1つのテーブルに大量のデータが保管されると、新規データの登録時に時間がかかる。そこで、テーブルを分割するというアイデアが浮かんでくるが、テーブルの分割をプログラム側で対応すると、手間がかかりすぎるし、切り替え時にサーバを止めるタイミングも難しい。

実は、MySQLにはこのような状況に対応するためのMERGEテーブルというものがある。データが多くなったらMERGEテーブルとUNIONで既存のテーブルと新規のテーブルを1つのテーブルとして扱うようにすればいい。検索を実行するときは新旧テーブル全体を対象にして、データを登録するときは新しいテーブルを対象にできるなど、非常に都合がいい。テーブルの作り方を工夫すると連番も前のテーブルを自動的に引き継ぐのでさらに安心だ。

お客様のサーバで複数のテーブルを分割したが、osCommerceを稼働させたまま瞬時に作業を終わることができた。
ただし、準備に時間はかかった。

http://dev.mysql.com/doc/refman/4.1/ja/merge.html

osCommerceやZen Cartのバージョンによっては注文関連のテーブルにインデックスを設定するとパフォーマンスが改善される。
ただし、丁寧にすべてのカラムごとに１つのインデックスを設定すると、インデックスが効果的に機能しない。
「実践ハイパフォーマンスＭｙＳＱＬ」の６６ページに、「ＭｙＳＱＬでは、１つのクエリを実行するとき、１つのテーブルにつき１つのインデックスしか使用できないのである」と書かれている。とすると、WHERE句で指定される検索条件に使用されるカラムが何個もある場合は、せっかく設定したインデックスが無駄になるということになる。
こんなときは、複合インデックスにすると効果的。ＭｙＳＱＬでは、１つのインデックスに対して１５カラムまで１つのインデックスに設定できる。
注文関連テーブルの場合も、クエリを確認して、検索条件中のカラムを同一のインデックスに設定するといい。
phpMyAdminなどを使って、EXPLAINで分析しながら調整するとわかりやすい。
あるとき、トップページだけ時間がかかるので調べてみたら、ベストセラー（ランキング）を表示しているモジュールの中のクエリに時間がかかっていた。「WHERE」以降にはカラムがひとつあり、「ORDER BY」以降にもカラムがひとつあって、同じテーブルに属していたのでこの二つのカラムで複合インデックスを作ったら、2秒近くかかっていた処理が0.024秒に短縮された。

詳細は以下のＵＲＬで確認してください。

http://dev.mysql.com/doc/refman/4.1/ja/mysql-indexes.html

http://dev.mysql.com/doc/refman/4.1/ja/multiple-column-indexes.html

お盆で街は休止状態ですね。

さて、Aspire 5720Gは、ひとつひとつ不具合を解消していくことでフリーズしない時間が長くなってきた。しかし、まだ、フリーズする。
ノートPCなので当然のように作業を終わるとスリープにしていたが、スリープから復帰後にフリーズするようだ。何度か試してみたが復帰後にフリーズ。
以前は検索しても情報が数件程度しかなかったが、今は、似た例をいくつも見つけることができる。どうも、スリープでフリーズすることがあるらしい。
スリープではなく休止状態にして、何度か試してみると、フリーズしなくなった。

今度こそ大丈夫かな。
長時間動画を表示させても熱で止まることもないしAspire 5720G自体は良いマシンなのかもしれないが、正常に動作するまで手間がかかりすぎた。