2.11系から2.12系 [EC-CUBE メモ]
ALTER TABLE dtb_products_class ADD COLUMN classcategory_id1 INT NOT NULL DEFAULT 0; ALTER TABLE dtb_products_class ADD COLUMN classcategory_id2 INT NOT NULL DEFAULT 0; -- MySQL は下記も追加する (設定によっては、WHERE でキー指定の無い UPDATE を実行できないため) -- SET SQL_SAFE_UPDATES = 0; UPDATE dtb_products_class SET classcategory_id1 = COALESCE( ( SELECT classcategory_id FROM dtb_class_combination WHERE class_combination_id = d
DB設計を見直してEC-CUBEを高速化する - [EC-CUBE/PHP] ぺんたん info
EC-CUBEのDB設計は、お世辞にもきれいとはいえない。 MySQLでいうと、文字列型はすべてTEXT型になっている。 インデックスすらあまり使われていない。 dtb_session の sess_id は一意なはずなので、ユニークにしたほうがいいと思います。 プライマリキーに変更する。 ALTER TABLE `dtb_session` ADD PRIMARY KEY ( `sess_id` ( 32 ) ); ALTER TABLE `dtb_session` DROP INDEX `dtb_session_sess_id_key`; またテーブルやカラムの照合順序は、データベースの照合順序が継承される。 もし照合順序が utf8_general_ci だったり utf8_bin となっている場合は、utf8_unicode_ci に変更したほうがいい。 特に大文字、小文字の区別をす
ECCubeMySQL – スイッチサイエンス
EC-CUBEを手っ取り早く高速化する EC-CUBEが遅い。むちゃくちゃ遅い。死ぬほど遅い。 事実、重くて重くてお客様が注文できないことさえ有った。 有った、って過去形なのは、高速化できちゃったから。 なんと、EC-CUBEをインストールしただけでは、バックエンドのデータベース（MySQL）にインデックスを付加してないのです。 そのくせ、テーブルは数百から数千レコード有るうえ、複雑な検索問い合わせを多用しています。 インデックスが無いと、逐次検索を行います。 nレコード有るテーブルと、mレコード有るテーブルとから検索すると、n×m回の逐次検索を行うのです。 おかげで、1億回の逐次検索で数時間CPUを占有とか、ばかな状況になっていました。 なんで、こんなことになってるんでしょうね？ 問題に気づいたら手でインデックスを付けろってことなのでしょうか。 要するに一種のバグじゃないかなと思います。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
