MySQLの最先端を行く現場人が集う MySQL Casual Talks #6に行ってきた！ - もぐめぽろぐ
TokuDBとはTokutekが作ったFractalTree(R)Indexを実装したストレージエンジン 特徴 オンラインALTER TABLE(ADD INDEX, ADD COLUMN)に対応 圧縮がイケてる 断片化しない クラスターインデックスを複数作れる infromation_schema, show engine tokuDB で情報みれるがなれるのに時間かかる foreign keyは対応してない How TokuDB Fractal TreeTM Indexes Work ランダムライトなインデックスの構築が早い InsertのTPSはいつまでもスループットが変わらない テストケース twitterみたいなことをやろうとした テーブルをクロスしてtimelineテーブルを作る timelineテーブルは6億件 ファイルサイズ図ったらinnodb compactは60G弱、
MySQLのパーティショニングのハマリ所 - sakaikの日々雑感～(T)編
今までマニュアルを斜め読みした程度で「MySQL 5.1 から使えるようになったパーティショニング。便利そうだな」などと思っていたのですが、このたび実際に使いたいシーンが出てきたので、利用を前提に調べてみました。 そしたら、ハマることハマること。やりたいことは、日付カラムで１日ごとのパーティションにしたいだけだったのですが（向こう２年分くらいパーティション作っておいて、運用で「古いパーティション削除→新しいのを追加」でいいかなと考えていました）、これができない。 ハマりの原因は「パーティショニングの条件は、プライマリーキーの一部でなければならない」という制約。 http://dev.mysql.com/doc/refman/5.1/ja/partitioning-limitations.html 今回使用を検討したテーブルはプライマリーキーが重要だったので、 CREATE TABLE pt
MySQL 5.5から使えるようになったRANGE COLUMNSによるパーティショニング - There's an echo in my head
それまで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
MySQLのパーティショニングで必要そうな工夫 - cloned.log
MySQL 5.1のパーティショニングを試してみた。マニュアルはMySQL :: MySQL 5.1 リファレンスマニュアル :: 15 パーティショニングを参照のこと。試してみた環境は、MacのParallels Desktop上のCentOS 5。 まずはMySQL 5.1をソースからインストール。マニュアルには次のように書かれている。 ソースからコンパイルする場合には、--with-ndbcluster、--with-partitionオプションとともにconfigureを実行して下さい。 MySQL :: MySQL 5.1 リファレンスマニュアル :: 15 パーティショニング この通りにすると、ここの記載のように非推奨オプションだと言われてしまうので、--with-pluginsを使って指定するようにした。今回の味見configureオプションは次の通り。 ./configur
パーティショニングの使用例 - http session情報
今日もパーティショニングの話の続きである。 パーティショニングが非常にフィットする（たぶん昨日の例よりも）もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDB（MySQL Cluster）ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、イン
MariaDB(MySQL) - パーティショニング！
mk-mode.com Linux, Debian, IT, Server, PG, Ruby, Rails, Python, C++, Fortran, PC, MariaDB, math, GIS, etc... MySQL 5.1 から導入されたテーブルのパーティショニング（１テーブルの分割管理）についての備忘録です。 パーティショニングすることにより主に以下のようなメリットがあると考えられます。 対象のパーティションのみ参照するようになるため、高速化が見込まれる。 パーティションごと削除が可能であるため、管理が楽になる。 （以下、乱文ご容赦ください） 0. 前提条件 MariaDB(MySQL) 5.5 系、5.6 系での作業を想定。 （5.1 以降ならパーティショニング可能であるが、RANGE で date 型, datetime 型がそのまま使用できるのは 5.5 以降） 1.
今日の MySQL - Partitioning 編 - - 日向夏特殊応援部隊
さてと、ありがちな下記のようなテーブルを作ってみます。ちなみに 5.1.45 で試してます。 DELIMITER ; DROP TABLE IF EXISTS diary; CREATE TABLE diary ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `subject` varchar(64) NOT NULL, `content` text NOT NULL, `created_on` datetime NOT NULL, `updated_on` datetime NOT NULL, PRIMARY KEY (`id`,`updated_on`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 PARTITION BY RANGE ( to_days(updated_on)) ( PARTITION p
MySQLパーティショニングの設定、追加、削除、再構成 - Qiita
まずこんなテーブルを作るとします。ここに毎月10万件以上のレコードが入ってくる予定です。 1レコードが57byteなので、月に5.7Mbyte、プライマリーキーを入れると60Mbyteくらいが入ってきます。 年間にすると720Mbyteなので、まぁデータ量的には余裕だと思うのですが、 100万レコードを超えるとレスポンスが鈍化するという印象があります。 というわけで、MySQLにあるパーティショニング機能を使い、データを振り分けたいと思います。 【参考】DB設計時のサイズ見積もり | よねのはてな テーブル作成 注意する点として、パーティショニングのキーにしたいカラムを、プライマリーキーに含める必要があるようです。 なので、オートインクリメントのカラムがあるテーブルだと辛い。構成を考えなおした方がいいかも。 CREATE TABLE `list_rtx` ( `member_id` var
MySQL の (big)int 型とストレージの微妙な関係 : にぽたん研究所
以前、MySQL について、こんな事を書いた事がありました。 MySQL の auto_increment が duplicate key になる恐れint(10) unsigned で、auto_increment だと、1 〜 4,294,967,295 までしかインクリメントしないから、仮にもし「1 日 100 万レコード」ずつ INSERT されたら 11 年と 9 ヶ月ちょっと経つと duplicate key が発生してしまう！！だからと言って、int 型だと恐いよー！ってヒヨって bigint(20) unsigned で auto_increment なんかしたとしても、1 〜 18,446,744,073,709,551,615 までしかインクリメントしないから、仮にもし「1 日 100 億レコード」ずつ INSERT された日にゃ 5,050,546 年 11 ヶ月と
姫ヒャクを支える技術(MySQL編)
ゆるふわアグレッシブ運用 マスター一台で頑張る SLAVE参照とかなるべくしない。SLAVEはあくまでバックアップ RDSのMulti AZ最高 データをメモリに載せきる シャーディングとかなにそれ AGENDA テーブル設計 データ量を抑える工夫 論理削除を使わない パーティション データの不整合を防ぐ仕組み FOR UPDATEは銀の弾丸ではない(未完成)
MySQLクエリパフォーマンス改善簡易まとめ - Qiita
数年やってないと記憶の彼方に飛んでいきそうだったので、MySQLのクエリ改善方法のテンプレを自分用に明記。 スロークエリを除去する事。 初めはとにかく観察。スロークエリを出力させて、観察する。 indexが効かないクエリを排除する。 indexが予期できない条件分岐によるクエリを廃止する。 場合によってはソートをさせない。コード側でソートさせる。 JOINをわざとさせないのも一つの手。後にDB分離レベルのシャーディング等が発生する可能性のあるようなシステムでは、JOIN禁止にする事は決して間違ってはいない。 indexを必ず効かせる レコード数に応じて、割当たるindexが異なることがあるので、必ず同じデータ数か実際の運用環境で検証すること。 但し、indexを増やし過ぎると、挿入時に更新対象が増えるため、必要最低限にすること。 explain してindexを確認する 特に注目しなければ
mysqldとmysqld_safeの関係 – OpenGroove
mysqldとmysqld_safeの関係について。 mysqld_safeはMySQLを安全に起動するためのプログラム、くらいの認識はあったのだが、 では具体的に何がどう安全なの？．．．と、なると答えに詰まるので、改めて書いておく。 MySQLのインスタンスはmysqldを直接起動するのではなく、mysqld_safeを経由して 起動させることが推奨されている。 mysqld_safeはひと言で言うとmysqldを監視しているデーモンである。 # /etc/init.d/mysql startを実行した時というのは、mysqldがダイレクトに起動 しているのではなく、mysqld_safe内で起動している。 つまり、mysqld_safeが内部でmysqldを実行しているのである。 しつこいが起動の流れを改めて書くと、以下のようになるわけだ。 # /etc/init.d/mysql st
[mysql]indexが使われていないSQLを調べる方法
log_queries_not_using_indexesというオプションを有効にすることによって、indexが使われていないSQLを抽出することができる。 log_queries_not_using_indexesオプションの値の確認・設定方法 global variablesの値が「on」になっていれば、indexが使われていないSQLが抽出できます。 mysql> show global variables like '%indexes'; +-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+ | log_queries_not_using_indexes | ON | +------------------------
MySQL InnoDBの行レベルロック
この機能はMyISAMにはなかったものなので、自分用のメモを書きました。 行レベル・ロックとは 行レベル・ロックは「レコード単位のロック機能」のことです。1レコードだけロックされるわけではなく、対象となる複数レコードがロックされます。 innoDBテーブル・タイプでは、レコード更新時とSELECT文（ロック・オプション付き）で行レベル・ロックが行われます。 読み取り時のロック 通常の「SELECT .. FROM ..」というステートメントでは、いっさいロックされません。また、読み取り一貫性機能によって、こういったクエリーを実行した後に、他でロックしても読み取りを続行することは可能です。 読み取り時にロックしたい場合、明示的にロック方法を指定する必要があります。 ロック方法 SQL 共有モードでは、まだ残っている更新トランザクションが存在したら、まず、そのトランザクションが終了するまで待機
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
MySQLの行ロックのふしぎ挙動で夜も安心して眠れない | 三鷹台でひきこもるプログラマの日記
MySQLのびみょーな行ロックに悩まされたのでメモ代わりに。 全部MySQL5.5でInnoDB使っている時のお話デス。 こんなテーブルが有るとしますよ。 create table table001 ( id int primary key, name text ); そしてこんなデータが入っています。 A> select * from table001; +----+-----------------+ | id | name | +----+-----------------+ | 1 | 水瀬伊織 | | 2 | 伊織さま | | 3 | いおりん | | 4 | デコちゃん | +----+-----------------+ まあ、データの中身は気にしない方向で。 そんなアイマス好きのAさん。 伊織さまを「デコちゃん」呼ばわりしている id=4 が許せないので書き換えてやろうと決
MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.7.2.4 読取りのロック
データのクエリーを実行してから、同じトランザクション内で関連データを挿入または更新する場合は、通常の SELECT ステートメントで十分な保護が提供されません。 ほかのトランザクションは、クエリーが実行されたばかりの同じ行を更新または削除できます。 InnoDB では、追加の安全性が提供される 2 つのタイプのロック読み取りがサポートされています。 SELECT ... FOR SHARE 読み取られる行に共有モードロックを設定します。 ほかのセッションもその行を読み取ることができますが、トランザクションがコミットするまで変更することはできません。 これらの行のいずれかがコミットされていない別のトランザクションによって変更された場合、クエリーはそのトランザクションが終了するまで待機してから、最新の値を使用します。 SELECT ... FOR SHARE は SELECT ... LOCK
MySQL - InnoDBのロック関連まとめ - Qiita
メモ開放。InnoDBの行ロック関連について、それぞれの項目が必ずしも並列関係にあるわけではないが、以下のようにまとめていく。 排他ロックと共有ロック SELECT ~ FOR UPDATE SELECT ~ LOCK IN SHARE MODE 排他ロックと共有ロック 読み取りを許すかどうかの違い。排他ロックは対象行を全てのクエリからロックするため、UPDATEやDELETEなどの更新クエリはもちろん、SELECTなどの読み取りクエリも通さない。共有ロックは更新クエリを通さないが、読み取りクエリは通す。 （追記：排他ロックは分離レベルによってはSELECTを通すとのこと。 公式 ） 排他ロックは全てのクエリを通さず、共有ロックは排他ロックを伴うクエリを通さない、と言い換えたほうがいいかもしれない。 公式では共有ロックは同トランザクション内のselectを許し、排他ロックは同トランザクショ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Zaim 500万ユーザに向けて〜Aurora 編〜
MySQLで簡単にランダムなテストデータを作成する方法 - Qiita
