チューニング

【最初から大きくなることが分かっているテーブルを分割して別々のサーバーに置くことを前提に作成する。】これが大事らしいです。

後から分割することもできるがとても難しいので，新しく作成する時にはあらかじめ分けてしまうのだそうで。 これはサーバーの数によって変わるのではないというのもなかなか興味深いです。

例えば購入履歴であれば日ごとのテーブルにしたり，所持カードのリストであればユーザーidでmodを取って100分割したテーブルをサーバにマッピングするそうです。実際のサーバーは5台で足りる場合は，1～20までをサーバー1へ，……みたいな作り方を考えておくと良いとのこと。勉強になります。

スループットを増やすには⇒スレーブを増やす。参照クエリの数が増える時は何とかなる。多段スレーブにする。が，やりすぎると遅延の問題が出てくるので，10台から15台くらいでおさめたい。スケールアップとしてメモリを増やしたり，Fusion-ioを使うとかでも対応する。
クエリのチューニングcoverning index（selectの取るカラムを全部indexに全部入れてしまう。容量は巨大になるが高速），index full scan（これはここでは説明できないので，特殊なケースにおいて高速化できる。調べてください）このあたりで対応する。
スライドには記載されていませんでしたが，素晴らしい情報でした。

負荷対策の実例として行ったことは
→スケールアップとInnnoDB化。
1master/6slaveで運用中のDBセット
月に数回SlowQueryが発生してレプリケーションの遅延が発生する
memoryを16GBから24GBへ
Slaveを3台に

http://gihyo.jp/news/report/01/phpcon2012/0001

なるほど、なるほど。