EC-CUBEをチューニング - MySQL：テーブル設計 - カラムの型
EC-CUBEの新バージョン、2.5.0の開発が開発合宿でかなり進んだ様です。僕も参加したかったのですが、諸事情により参加出来ませんでした。*1
EC-CUBE2.5.0では、MySQLへの対応がかなり改善されていて、パフォーマンスもかなり向上しているとの事です。
いやー、楽しみですね。
しかし、現在EC-CUBEでECサイトを運営されている方は、MySQLへの対応が不完全なバージョンを利用しており、2.5.0がリリースされるまでは2.4.4以下のバージョンを使い続けなければいけません。
また、仮に2.5.0がリリースされたとしても、バージョンアップ作業は大変でしょうし、すぐバージョンアップは出来ないと思います。*2
そこで、このEC-CUBEをチューニング - MySQL編もまだ需要があると思いますので、続きを書いてみます。
前回のEC-CUBEをチューニング - MySQL：準備編で、EC-CUBEに大量の商品データを登録するところまでやりました。
今回は、テーブルの構造を出来るだけ変えずにパフォーマンスをアップさせる方法です。
レンタルサーバ等ではMySQLのパラメータの設定を変更出来ない環境も多いと思うので、テーブルやカラムの設定変更だけで出来るだけパフォーマンスを上げます。
前回準備した環境では遅過ぎて作業に支障が出るので、VM上に再度環境を構築しました。
PHP 5.2.13
MySQL 5.1.39
- 大カテゴリ
- 5
- 中カテゴリ
- 4
- 小カテゴリ
- 4
- 規格1
- 5
- 規格2
- 5
- 商品数
- 1000
標準の状態では全商品一覧の表示に13960msもかかってしまいました。遅いですねー
カラムの型を変更する。
EC-CUBEでは、テキストデータが入るカラムがtext型になっています。*3
しかしMySQLではtext型が設定されているカラムはインデックスに指定出来ませんし、min()等の関数で処理する際もかなり遅くなってしまいます。
なので、
をchar型に変えてしまいます。
結果は10843msになりました。ちょっと速くなりましたね。
「おいおい、チューニングで大切なインデックスは？」
とツッコミたくなる方もいらっしゃると思いますが、EC-CUBEをMySQLで動かす場合、PostgreSQLで動かす時のviewをサブクエリをガンガン ネストして表現しているので、あんまり意味がありません。
むしろ遅くなる事の方が多い様です。
次回は、もう少し踏込んで、テーブルを変えずにもっと劇的に変わる方法をご紹介します。
