ログテーブルのようなすごい巨大なテーブルがあって、古いログはいらないから削除したい、でも万が一のときにデータはどこかに取っておきたいというときは、 --complete-insert カラム名を含んだ、完全なINSERTステートメントを使用 --no-create-info ダンプされたテーブルを再作成するCREATE TABLEステートメントを書かない --where WHERE状態に選択された行のみダンプ このあたりをオプションに含めて置くとよいのかなーと思った。 # mysqldump -u$user -p \ > --default-character-set=utf8 \ > --complete-insert \ > --no-create-info \ > --where="created_at>='2012-04-01 00:00:00' and created_at<'2
まずこんなテーブルを作るとします。ここに毎月10万件以上のレコードが入ってくる予定です。 1レコードが57byteなので、月に5.7Mbyte、プライマリーキーを入れると60Mbyteくらいが入ってきます。 年間にすると720Mbyteなので、まぁデータ量的には余裕だと思うのですが、 100万レコードを超えるとレスポンスが鈍化するという印象があります。 というわけで、MySQLにあるパーティショニング機能を使い、データを振り分けたいと思います。 【参考】DB設計時のサイズ見積もり | よねのはてな テーブル作成 注意する点として、パーティショニングのキーにしたいカラムを、プライマリーキーに含める必要があるようです。 なので、オートインクリメントのカラムがあるテーブルだと辛い。構成を考えなおした方がいいかも。 CREATE TABLE `list_rtx` ( `member_id` var
Partition 周りで社内で説明する事が有ったのでせっかくなのでブログをかきます。 注.) 僕自身はMySQLにさほど詳しくはないので、完全には鵜呑みにしない事をおすすめしますが 下記のようなテーブルがあったとします CREATE TABLE messages ( id int unsigned NOT NULL, user_id int unsigned NOT NULL, content varchar(255) NOT NULL DEFAULT '', created_at int unsigned NOT NULL PRIMARY KEY (id), KEY `on_user_id` (user_id) ) Engine=InnoDB DEFAULT CHARSET=utf8; データ量が多かったりして、3ヶ月以前のデータをPurgeするとか考えだすとdeleteは重いので、め
MySQLのRANGEパーティションのお話です。 MySQL5.1からサポートされているパーティショニングですが、ログテーブル等、レコード数が多くなりがちなテーブルに日付でパーティショニングしてます。 最初から遠い未来までのパーティションを切るのは気持ち悪いし、長く運用されるサービスの場合は忘れる可能性もあるのでバッチを回すのがいいと思いますが追加する場合の手順と注意点です。 ・まずはパーティションを作成 CREATE TABLE `mura`.`test1` ( `date` DATE NOT NULL , `name` VARCHAR( 40 ) NOT NULL , `contents` VARCHAR( 255 ) NOT NULL , `created_at` DATETIME NOT NULL ) ENGINE = InnoDB PARTITION BY RANGE (TO_
それまでDATEやDATETIMEによるパーティショニングではTO_DAYS()関数を使って数値に変換する必要があったけど、MySQL 5.5からはRANGE COLUMNSを使うことによって日付や時刻をそのまま書けるようになった。 DATETIMEだとこんな感じ。DATEも同様。 /* パーティショニングに使うカラムを主キーに入れる必要があるのは相変わらず */ ALTER TABLE events DROP PRIMARY KEY, ADD PRIMARY KEY(id, created_at); /* RANGEではなくRANGE COLUMNS、パーティショニングするカラムの比較値もそのまま */ ALTER TABLE events PARTITION BY RANGE COLUMNS(created_at) ( PARTITION p201303 VALUES LESS THA
A table that is partitioned by range is partitioned in such a way that each partition contains rows for which the partitioning expression value lies within a given range. Ranges should be contiguous but not overlapping, and are defined using the VALUES LESS THAN operator. For the next few examples, suppose that you are creating a table such as the following to hold personnel records for a chain of
2013年03月21日18:11 MySQL 今さらだけどMySQLのパーティショニング機能を試してみた 最近は花粉が飛んでて辛い季節ですがみなさまいかがお過ごしでしょうか。でももうちょっと我慢すればサクラの季節ですよ〜。花見良いですよね、飲みたいだけですが。 ・・さて、今回はちょっと必要になったので、MySQLのパーティショニング機能なるものを試してみました。存在は知ってたけど、実際に試してみたことは無かった…。 パーティショニングとは? これはどういうものかと言うと、MySQL5.1から使えるようになった機能で、ひとつのテーブルのデータを条件によって複数の領域(パーティション)に振り分けて管理することができる、というものです。例えば日別にデータを別々のパーティションに振り分けたり。 パーティショニングするとデータの削除が高速だったり(通常は削除ってものすっごい遅いけど、特定のパーティシ
今までマニュアルを斜め読みした程度で「MySQL 5.1 から使えるようになったパーティショニング。便利そうだな」などと思っていたのですが、このたび実際に使いたいシーンが出てきたので、利用を前提に調べてみました。 そしたら、ハマることハマること。やりたいことは、日付カラムで1日ごとのパーティションにしたいだけだったのですが(向こう2年分くらいパーティション作っておいて、運用で「古いパーティション削除→新しいのを追加」でいいかなと考えていました)、これができない。 ハマりの原因は「パーティショニングの条件は、プライマリーキーの一部でなければならない」という制約。 http://dev.mysql.com/doc/refman/5.1/ja/partitioning-limitations.html 今回使用を検討したテーブルはプライマリーキーが重要だったので、 CREATE TABLE pt
実施する必要はほとんどないと思いますが、AUTO_INCREMENT をもった PRIMARY KEY を削除したい場合、 ALTER TABLE hoge DROP PRIMARY KEY; とすると Incorrect table definition; there can be only one auto column and it must be defined as a key なエラーとなるので、まず PRIMARY KEY に INDEX を追加して(ここでは id というカラム名としています) ALTER TABLE hoge ADD INDEX id (id); これが終った後に PRIMARY KEY を削除することができます。 ALTER TABLE hoge DROP RRIMARY KEY; この後にカラム自体も削除したい場合は、ふつーに DROP COLUMN
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く