Writing a MySQL storage engine: lessons learned
Single vs. multi-statement transactions MySQL distinguishes between single and multi-statement transactions. Single statement transactions are transactions that are executed in auto-commit mode. In auto-commit mode MySQL performs a commit operation after each statement. Multi-statement transactions consist of a BEGIN TRANSACTION and a COMMIT command. All statements that are executed in between tho
いちいさんにお誘いいただいて、勉強会で発表をすることになりました。 InnoDB Deep Talk #1 : ATND おそらく初見では内容が難しいと思いますので、先に資料を公開しておきます。 プレゼンテーション資料 (PDF) テストデータ生成スクリプト (JdbcRunnerで利用します。) プレゼンテーション資料からリンクしているウェブサイトの一覧です。 MySQL Bugs: #64567: Last_query_cost is not updated when executing an unique key lookup Understanding and Control of MySQL Query Optimizer: Traditional and Novel Tools and Techniques: MySQL Conference & Expo 2009 - O'R
縁あって仕事でMySQLを使いそうなので、いまのMySQLがどうなっているのか少しずつ調べている。 で、現在のデフォルトストレージエンジンであるInnoDBの設計思想に困惑している。 InnoDBは主キーを強制的にclustered indexにするとのことだが、それって何の役に立つのだろうか？ 何のためのclustered indexか？ clustered indexの利点は 一般のb-tree indexに比べて、range scanが圧倒的に速い*1 大量データ同士を最速で結合する「ソートなしMerge Join」が使える の2点だ*2。 これらの利点の代償として 行長を拡大するような更新が多発するとスキャンが徐々に遅くなっていく 主キー値が昇順になるようにinsertしないとスキャンが徐々に遅くなっていく ROWIDが存在しないので、セカンダリインデックスを経由するデータアクセス
All of Percona’s open source software products, in one place, to download as much or as little as you need.
[<<][<][>][>>] [<<][<][>][>>] Generated by Rabbit version 1.0.5
突然、MySQL用のVPストレージエンジンが気になったので試してみました。 VP(Vartical Partitioning)とは、文字通りテーブルの縦分割のことで、カラムがいっぱいあるテーブルをバッサリと縦に切って（もちろんPRIMARY KEYのカラムは両方に持ちますよ）別々のテーブルに分けて管理するというもの。 これだけなら、テーブルを分割したあとで、アプリケーションのほうで必ず両方のテーブルの整合性が保てるように追加／削除／更新をすれば良いだけなのですが、「だけ」とは言ってもこれは結構面倒。VPストレージエンジンを使うと元のテーブルレイアウトのままでもアクセスすることができるのです（親テーブル／子テーブル群 的に考えるとイメージがわきやすいでしょうか）。 まずは試してみます。Windows上で細かいことは気にせずにさくっと*1。 http://spiderformysql.com/
Ulf Michael Widenius (born 3 March 1962), also known as Monty, is a Finnish software programmer. He is the main author of the original version of the open source MySQL database, a founding member of the MySQL AB company and CTO of the MariaDB Corporation AB. Additionally, he is a founder and general partner at venture capital firm OpenOcean. Born in Helsinki, Finland, Widenius went to the co-educa
2011-07-28 InnoDB純正の全文検索エンジンInnoDB FTS つい先日、MySQL-5.6.3-labs版がリリースがされました。この中にはInnoDBで動作する全文検索エンジン"InnoDB FTS"が含まれています。これまでは、MySQLとInnoDBの組み合わせで全文検索を行うためにはサードパーティの製品(mroonga 等..)が必要でしたが、これでズバっと選択肢が広がることになります。しかもInnoDBの開発チームが自ら開発した"純正の"エンジンということですから、これは大きな期待が持てます。 いったいどのような製品に仕上がっているのか、ざっくり記事やソースを読んで得た感触を述べてみたいと思います。 written by daijiro.mori どんなエンジンか? エンジンの概要については、 Overview and Getting Started with I
連載記事一覧は*こちら*にあります。 http://mirz.jpでまとめて読むこともできます(オススメ)。 今回はストレージエンジンインタフェースについて。かなりボリュームがあります。 handlerクラス ストレージエンジンのインタフェースはhandler抽象クラスによって定義されています。このhandlerクラスはテーブルのopenやclose、テーブルの順次走査、インデックスを利用したレコードの検索、レコードのソート処理、レコードの削除など、基本的な操作を行うためのメソッドを定義しています。 handlerクラスはsql/handler.hに定義されており、メソッドの実装はsql/handler.ccで行われています。またhandlerクラスはSql_allocクラス(sql/sql_list.h)を継承しています。MySQL内部では、各テーブル記述子ごとにhandlerインスタン
連載記事一覧は*こちら*にあります。 http://mirz.jpでまとめて読むこともできます(オススメ)。 ストレージエンジンインタフェースの続き。忙しくなってきたのでビルド待ちの時間にコツコツ書いていたものをUP。 handlerクラスのメソッド(続き) メソッド定義 メソッドの説明 virtual int rnd_same(byte *buf, uint inx) 引数inxが0以上の場合、inxをキー番号として現在のレコードを読み取り引数bufのバッファに格納する。成功した場合に0を返し、失敗した場合には0以外のエラーコードを返す。現在、このメソッドはどこからも呼ばれておらず、オーバーライドしているストレージエンジンも存在しない。デフォルトの実装は、HA_ERR_WRONG_COMMANDを返す。しかしながら、MEMORYエンジンとMyISAMエンジンはこのメソッドの実装を提供する
MyISAMとInnoDBのどちらを使うべきか
Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL
Wild Growth
MySQL 5.7 and 8.0 have an issue of stopping replication on all slaves. I'm pleased to announce the release of Spider storage engine version 3.2(rc) and Vertical Partitioning storage engine version 1.1(beta). Spider is a Storage Engine for database sharding. http://spiderformysql.com/ Vertical Partitioning is a Storage Engine for vertical partitioning for a table. http://launchpad.net/vpformysql Pl
2010年04月25日00:16 NoSQL MySQL 10分で理解するMongoDBのパフォーマンス MongoDBってスキーマレスなDBで、カラムが決められないような場合に使うと効果的なんだと思うんですが、「そういうデータはハッシュにして、JSON 形式で MySQL に保存すれば良いのでは？」という意見をいただいたので、その場合とのバフォーマンス比較をしてみました。 ※最初は MySQL として innodb でしか評価していなかったため、myisam の結果についても追記しました。(2010/04/25追記) ベンチマーク環境の準備 試した環境としては、MySQL 5.1.45, MongoDB 1.2.4 です。MySQL側はこんな感じ。 mysql> desc blogs; +------------+--------------+------+-----+---------
MySQL 5.5をわずか30秒足らずでコンパイルするためのテクニック
べっ・・・別にソースコードなんて自分でコンパイルしないんだからねッ！！などと言わずにまず聞いていただきたい。30秒でMySQLのコンパイルが出来るというこの事実を。最近、細々とビルド時間の短縮に取り組んでいたのだが、正直ここまで爆速になるとは思わなかった。今日はビルド時間短縮のためのテクニックを紹介するので、是非皆さんも参考にして、快適ビルド生活を送って頂きたい！！ 自己ベストは26.262秒マシンの状態や負荷の状況によって多少ビルドにかかる時間は前後してしまうのだが、これまでの自己ベストはなんと26.262秒。平均すると30秒ぐらい。以前は1分を切ることがなかったのだが、今ではなんとその半分でビルドが出来てしまう。これは純粋にmakeをするのにかかった時間であり、cmake（MySQL 5.5以降）やconfigure（MySQL 5.1以前）にかかる時間は除いてある。だがそれでも速い。
Section Navigation [Toggle] 19.4.4 Connector/J (JDBC) Reference19.4.4.1 Driver/Datasource Class Names, URL Syntax and Configuration Properties for Connector/J 19.4.4.2 JDBC API Implementation Notes 19.4.4.3 Java, JDBC and MySQL Types 19.4.4.4 Using Character Sets and Unicode 19.4.4.5 Connecting Securely Using SSL 19.4.4.6 Using Master/Slave Replication with ReplicationConnection 19.4.4.7 Mapp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
