2.5について、先日の開発合宿時以降、商品数や規格・カテゴリが多いときの商品一覧の高速化について検討を重ねてきましたが行き詰まっています。

商品一覧の生成処理見直しにて、EC-CUBEの悪しき処理として、いの一番に取り上げられるIN句に何百ものproduct_idが並ぶ処理、多いときにはSQLのクエリ長制限に引っかかるような問題も解決し、その他実行処理の最適化も進めたことにより、PostgreSQL環境においては個人的に満足出来る速度、メモリ使用量での動作を得ています。

しかしながら、全くの同一条件・同一環境・同一クエリにおいてMySQL環境では速度が出ません。
具体的にはテストデータ作成スクリプトデフォルト値で作った商品情報において、PostgreSQLにて 0.46秒 で得られるクエリが、 MySQL 5.1.52ですと 17分以上かかるという状態です。(PostgreSQL8.4.5、MySQL5.1.52、メモリ4GB、Core i7-640、Windows XAMPP 64bit環境比較）

※もちろん商品数が少ないときは必要十分な速度が出ます。例えば、MySQLで１カテゴリに１万商品をぶら下げた際の表示は高速化しています（上記環境で45秒、以前はクエリの文字制限に引っかかったりして実行すら不可かな？テストデータの状態自体、特殊なのであれですが・・）。

原因はMySQLが伝統的にORDER BY句に弱いという根本的問題にあり、解決の方法はいくらでもあるのですが、それをすると環境依存したり（バージョン依存やレンサバによって動作不可）、PostgreSQL側の速度が大幅に落ちるという、片方を取れば片方がダメという状態です。

個人的には環境依存をしない実装で、かつ同一SQLへの統一の限界点を感じました。

あとはDBによって分岐させてクエリ自体または処理構造自体を変えないと、中々大幅に高速化するのは現状のDB構造では難しいなと思っています。
またMySQLの将来バージョン開発作業をチラ見していると、色々と大幅見直しがされているようなので先々は徒労に終わりそうな感じもあります（リリースは迷走してるので、いつになるか分かりませんが）。

とりあえず、商品一覧の高速化に対しては当方としては現在のコミット内容で打ち止めです。
どなたか汎用性と高速化を両立するような美しいコードありませんか？

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h