ショップ系DBのアクセスが多すぎて、
304が多くなるようにして負荷対策したけど、
一応304は多くなったんだが、まだ全然ダメぽかったんだが、
likeでリストのアイテムを抽出するんだが、
以前にもだいぶ改善した上でファイルにキャッシュするようにしたんだが、
まだソートする箇所がいくつかあったんで、そこら見直した。
抽出用キーがソートキー順で並ぶようなインデックス作っても、
likeで抽出だと抽出用キーが複数あるわけで、再ソートしなきゃいけなくなるんだよね。

リストページはロボ遮断してるから、
304対策は商品ページのアクセス回数軽減策だが、
商品ページのDBアクセスはコードの完全一致で抽出するから、DB負荷はかからんのだよね。
DBの負荷が問題になるとしたら、やっぱリスト作成の時だよな。

で、サブカテゴリ検索の時はソートしない様にしてたんだが、
トップページとAtomフィードでソートしてたから、そこで激重くなって死んでたと思う。
トップページとフィード用の抽出キーはlikeじゃなくて=でやろう！
ってわけで、カラム追加しようと思ってポチッたんだが、
Apache止めずにカラム追加とかやったら、死ぬねw
で、MySQL強制停止しなきゃいけなくなってDB壊れた。
まあ、前によく壊して慣れたからすぐ復旧できた。

で、ポチってすぐ気づいたけど、
トップページとフィード用の抽出キー（ルートカテゴリ）を新たに用意しようと思ったが、
よく考えると、Amazonとか最上位ページのブラウズノードが最上位ノードとは限らんよね。
この仕組みはダメだ。

で、完全ソートはできなくなるが、
今までどおりカテゴリツリーをlikeで抽出して、
カテゴリツリーのインデックスが最初からソートされてれば、
カテゴリ順になっちゃうが、カテゴリが完全に同じものについてはソートされた状態だから、
ある程度はソートされた結果が取れるよね。
ってわけで、インデックスの見直しで対処した。


とりあえず、
バックアップデータで復元して、インデックス再構築してApache起動させといた。
変更箇所多かったが、リストページとフィードは全部orderははずした。


アクトレAPIのDBとサイトもAmazon系DB置いてる鯖に移そうとしてたが、
今は様子見のが良さそうだ。