転がってる時は消すとうまくいくかも。schemaに新しいカラムが追加されたようで、そのままでは(起動はするけど)エラーが出てる様子。バイナリなので何してるのかよく分かりませんが、upgradeするようなsqlをなげているみたい。slaveがいたらupgradeもslaveに伝播してきてちょっとハマった。あと、けっこうたくさんのテーブルでrepairが走ることになります。ディレクトリと認識されてしまうこと。masterした直後のposが98から106に変わりました。いや、だからなんだってわけでもないですが...。partitionつくるすでにあるテーブルからコピーで分割することにします。MAXVALUE);そんで移行。fuga;うーん、MYDもMYIもいいかんじに分割されてます。悲しいエラーが発生してうまくいきませんでした。どこかに保存するときにメモリに乗せているのかな。fuga_fdr;とかやってみたけど変わりませんでした。部分がクライアントとしていけてないってことなのかな。なんかバグっぽい気もする。えらい人に散々言われたように、ちゃんと報告しなきゃだなー。selectしたけど、直接alterしてみるとどうなるかな、と思ってやってみた。...);まあふつうにうまくいきました。速度とか気にしてなかったのでサーバに他の負荷があったかわかんないんだけど、50分が5分くらいに変わりました。ついでなので元に戻してみる。書き方が最初わかんなくて困った。見るのがいちばん網羅的ですね。いう書き方ができるらしい。partition使ってないテーブルでもエラーにはならないので、いつもこれでいけそう。1つのパーティション内に収まるもの。sec)うん、まあ確かに速くなってますね。性能(2)つづいてパーティションをまたがるもの。sec)おおー、いいじゃないですか!!性能(3)最後。実際には途中までのパーティションにしかデータが入っていません。sec)うーん、やっぱ余分なパーティションまで調べてる的な遅さがあるのかな。partitionは(repairが必要だけど)あとで追加もできるので、あまり大きく取りすぎると良くないようです。'fuga_parted';で得ることができます。うーん、もうちょっと、かな。まとめ長くなってきたのでこのへんでまとめ。将来のことを考えずに肥大化してきたテーブルを分割したいときに、1回のalterで分割できる気持ちよさはあるんですが、結局おなじmysqldのインスタンス配下にあるのは変わりません。インデックスもどうせb-treeなので、なにも考えず適当に分割すると、パーティションを跨いでしまった場合にすごい遅くなっちゃうかもしれません。indexのみで済むときは当然遅くなると思います。それでもinsertはけっこう楽になりそうだし、もちろんパーティションを跨がなければ上で見たようにだいぶ速くなっているし、物理的にディスク分けることですごい速くなるとか、でかいファイルを扱うのがすごい遅いファイルシステムだとか、そういう場合はかなりの効果なんでしょう。いうことで、どんなインデックス張るかってのと同じように、うまく使わないといけなそうってことでした。思ってちょっと外に出たら、今月のW+Dに特集ありますね。(のつもりだったけどただのメモ)タイトルまで書いたけど面倒になったんでやめた。メールを引越し昨日の続き。しようかと思ったけどやめた。join今日はもう一つ。r/月別アーカイブはてなブログをはじめよう!ichii386さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。