会員データと受注データが増えてきた場合の対応

受注データと会員データが増えてきた場合、購入時にタイムアウトする場合があります。

その場合の対応方法で、

データベースで負荷をかけない速い検索の方法は PRIMARY KEY もしくは 適切にINDEX を使用する事で

問題となる部分は

SC_Customer.phpの

    public function updateOrderSummary($customer_id)
    {
        $objQuery =& SC_Query_Ex::getSingletonInstance();

        $col = <<< __EOS__
            SUM( payment_total) AS buy_total,
            COUNT(order_id) AS buy_times,
            MAX( create_date) AS last_buy_date,
            MIN(create_date) AS first_buy_date
__EOS__;
        $table = 'dtb_order';
        $where = 'customer_id = ? AND del_flg = 0 AND status <> ?';
        $arrWhereVal = array($customer_id, ORDER_CANCEL);
        $arrOrderSummary = $objQuery->getRow($col, $table, $where, $arrWhereVal);

        $objQuery->update('dtb_customer', $arrOrderSummary, 'customer_id = ?', array($customer_id));
    }

この場合、大量の受注データ（dtb_order）からindexの効いてないカラムで検索し、さらに重たい集計処理を4パターン行なっていることが原因です。

この部分の速度を改善する方法はPRIMARY KEYを使用する事です。

この場合、dtb_orderなのでPRIMARY KEYのorder_idを使用できれば一番速く集計を行うことができます。

新しくcustomer_idとorder_idのカラムのテーブルを用意して、適切にindexを貼り会員が購入した時にそのテーブルにひたすたデータを入れていきます。

そのテーブルを元に先ほどのメソッドのクエリを書き換えると、 そのユーザーの今まで購入した受注のみPRIMARY KEYで絞り込んだ結果を集計するので、 受注件数によりますが速度が 劇的 に速くなります。

まだ何か所か受注データが増えた場合に重たくなる箇所がありますが、それは別の機会に。

今日も速いEC-CUBE仕上がってます。

お問い合わせはこちらから。