innodb_file_per_tableを設定した状態でテーブルのパーティショニングを行うと、パーティション単位でデータファイルができ、だいぶ扱いやすいサイズになった。innodb_buffer_pool_sizeは欲張るな!メモリの7割から8割のサイズを設定すると言われているが、とち狂って32Gに対して28G(約9割!)を設定してしまっていた。22G(7割程度)にしてかなりパフォーマンス改善。こちらが参考になった。−ゆめログ−更新処理時のデータのオーバーヘッドが大きい!truncateしたあと、データの挿入を行うとデータファイルが500Mに。あれ?テーブルをoptimizeすると、300M程度のサイズまで減少。engine=innodb」と一緒!放っておくとdb全体の容量がどんどん大きくなるので、何らかの対応が必要。今回パーティショニングの単位でデータの入れ替えを行うことにしているので、さしあたり以下の流れ。p1insertの後、テーブル全体でoptimizeするよりもパーティション単位にrebuildした方が効率がよさそう。statusが遅い!これがいまだに原因分からず、苦戦中。statusの実行に何秒もかかる場合がある。tables」となっているのをよく見かける。テーブル分割を行った結果、一つのスキーマに数百のテーブルができたが、これが原因かもしれない。いうわけで主に更新に関するあれこれを書いてみた。実際のところ更新に関しては、課題はある程度クリアできているのかなといった状況。参照の方のパフォーマンスについても少しづつ検証しているが、思ったようなパフォーマンスが出せず、けっこう前途多難な感じ。innodbはけっこうじゃじゃ馬ですなぁ。良さを引き出してナンボなので、もっと突っ込んでやってみようと思う。楽しみつつ!進展があればまた書いてみようと思います。Tokyoに参加してきた。Summit(一日目)に行ってきた。