知って得するInnoDBセカンダリインデックス活用術！
InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が
大人のためのInnoDBテーブルとの正しい付き合い方。
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
漢(オトコ)のコンピュータ道: モダンなMySQLの開発環境の構築方法
遅ればせながら モダンな Perl の開発環境の構築方法 モダンなPHPの開発環境の構築方法 モダンなPythonの開発環境の構築方法 モダンな Java の開発環境の構築方法 に続いてみる。MySQLは言語じゃないけど。 コンパイラ等MySQLをソースからビルドするのでなければコンパイラ等は必要ないけど、どうせアプリ開発に必要なので「MySQLなんかいつでもハックしてやるぞ！」という意気込みを示すために入れておこう。OSXならXcode、LinuxならGCC。最新のソースコードじゃないとヤダ！という粋な人にはBazaarのインストールもお勧めしたい。Bazaarは言わずと知れた分散バージョン管理システムであり、MySQL開発チームも採用している。最新のソースコードは次のコマンドでゲット可能だ。 shell> bzr branch lp:mysql-server/5.1 mysql-5.1
InnoDB Pluginことはじめ。快適ストレージエンジン生活はじまる！
MySQL 5.1.38からMySQL本体にInnoDB Pluginバンドルされている。一部の先駆的なユーザー以外に、「InnoDB使ってますよ！」もしくは「検証してるよ！」という話をあまり聞かない。そもそもであるが、InnoDB Pluginってなんぞ？！という人が多いんではないかと思うのだが、実際はどうなのだろう？現在はRC版（リリース候補版）という位置づけのInnoDB Pluginであるが、一部影響度の高いバグが残っていたりしてGA版ほどの安定性は求められないものの、ほとんど実用に耐えうる品質になっているといえる。そんなわけで、今日は改めてInnoDB Pluginの使い方・使いどころについて説明するので、ぜひ皆さんの手でInnoDB Pluginを評価してみて頂きたい。 なお、以下の解説は現在の最新バージョンである、InnoDB Plugin 1.0.6を前提にしているので、将
漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い（テーブルの行数を保持してる）のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基本的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ
違いが分かるエンジニアのためのMySQL/InnoDB/ZFSチューニング！
明けましておめでとうございます。今年もコンピューター道に邁進して参りますのでよろしくお願いします！ さて、今年一発目のネタはMySQL利用時におけるZFSのチューニングについて取り上げようと思う。Solarisに搭載されている機能の中でも最も注目度の高いものの一つであるZFSであるが、MySQLのバックエンドとしてはあまり利用されていないように思う。（そもそもSolarisのユーザー数自体がそれほど多くないという話もあるが。）ZFSは優れたファイルシステムであり、ファイルシステム自体にスナップショット機能が搭載されていたり容量の限界に先が見えない（充分すぎるほど余裕がある）といった管理上のメリットがあり、DBAにとっては垂涎のファイルシステムであると言える。（Linuxで利用出来ないのが難点だが、ZFSを使うためにSolarisを使うのもアリだろう。） MySQL利用時におけるZFSのチュ
My SQLのエンジンはInnoDBとInnoDBのどちらを使うべきか? | gihyo.jp
『Linux-DBシステム構築／運用入門』（翔泳社）をはじめ、MySQLに関する書籍を数多く執筆している松信嘉範氏による記事です。Webアプリケーションで使われることの多いRDBMSであるMySQLでは、主にMyISAMとInnoDBの2つのエンジンから選択できます。MyISAMのほうが高速でInnoDBはトランザクションに対応している、という違いはよく聞きますが、記事では最新の状況を踏まえ箇条書きベースで簡潔にまとまっています。 InnoDBは、リカバリが簡単でMyISAMに比べて時間がかかりません。また、オンラインバックアップができるなど、障害対応の観点から見て勝っています。さらに、MyISAMはテーブルロックであるのに対してInnoDBは行レベルでロックを行うため、並列性が高いことが挙げられます。 それに対してMyISAMは、WHERE条件なしのSELECT COUNT(*)がとて
MyISAMからInnoDBへ切り替えるときの注意点
MySQLを使い始めて間もない人がよく陥る罠の中に、気づくと使ってるストレージエンジンがMyISAMだった！ということがある。デフォルトのストレージエンジンはMyISAMなので、MySQLに詳しくない人たちが比較的陥りやすい罠なのだ。そもそもストレージエンジンという概念自体がMySQL独自のものなので仕方のない話である。MyISAMは素晴らしいストレージエンジン（たとえばこのYahoo!の中の人による投稿で言われているように）であるが、長所もあれば短所もある。例えば、 トランザクション対応ではない。 クラッシュセーフではない。 更新と参照が入り乱れた場合の同時実行性能がよくない。 テーブルが大きく（数億行とか）なるとINSERTの性能が劣化する。 などなど。特に前者の2つが問題で、アトミックな操作が必要なところでロジックを実装出来なかったり、サーバがクラッシュした時にデータがお亡くなりにな
Kazuho@Cybozu Labs: Comparing InnoDB performance on HDD, SSD, in-memory
Details: The benchmark was taken using MySQL 5.1.41 using innodb_plugin running on linux 2.6.31/x86_64 (Ubuntu 9.10 server). Options passed to sysbench were: --test=oltp --db-driver=mysql --mysql-table-engine=innodb --oltp-table-size=1000000 --mysql-user=root --mysql-db=test --oltp-table-name=test_t --num-threads=20 . My.cnf was set as follows. max_allowed_packet=16777216 query_cache_size=0 defa
MySQL InnoDBだけで全文検索 - SH2の日記
実験エントリです。 予習してみる 「転置インデックス」というキーワードで検索して、しばらく勉強してみます。 転置インデックス - Wikipedia mixi Engineers’ Blog » 転置インデックスを実装しよう ASCII.jp：悟空、秘剣「転置インデックス」を手に入れる ｜Googleはなぜ的確に探せるのか？ [を] 転置インデックスによる検索システムを作ってみよう！ 転置インデックスで学ぶ検索エンジンの中身アプリ - 睡眠不足？！ うーんなるほど。分かったような分からないような。 作ってみる とりあえず、Twitter4Jを使ってこんなデータを用意しました。ちなみに人選は漢(オトコ)のコンピュータ道: MySQLerのTwitterアカウントまとめ。を参考にさせていただきました。 5707049458,2009-11-14 20:28:34,sakaik,@hbstudy
(特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場
InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー
MyISAMとInnoDBのどちらを使うべきか
Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL
InnoDBの超高負荷更新処理安定性
最近は沢山CPUコアのある高速なサーバーとか高回転数のHDDが沢山付いたRAIDストレージとか、もの凄く更新系の負荷がかかるベンチマーク(「db_STRESS」 by Dimitriさん)とかがあるので、InnoDBの構成の更新系での様々な限界が見えてきています。 まぁ、現実的にそのような限界を突破する必要のあるシステムがあるかどうかは判りませんが、将来のためにも色々アイデアを加えてXtraDBを作成してきました。今、大幅な変更無しに実装できる範囲のオプションが揃ってきたので高負荷更新系処理のチューニングをXtraDBベースで一旦書き出してみます。 今回もサクサクとポイントだけ。 （IOスレッドを増やす とか、他でも語られている既知のものは省略します。） 今回のチューニングの方針は、 「mutexやrw_lockなどの競合をできるだけ避ける」 ということと 「あまり沢山溜めてはイケナイもの
SSDの真の性能を引き出す MySQL 5.1.38 InnoDB Plugin - SH2の日記
X25-M、SSDで検索してくる方が非常に多いので、本ブログ内のSSD関連記事をリストしておきます。 MySQLのベンチマークを用いたIntel X25-M SSDの評価 (2009/03/25) SSDの真の性能を引き出す MySQL 5.1.38 InnoDB Plugin (本記事) MySQL 5.1.38から本体に同梱されるようになった、InnoDB Pluginの性能検証結果です。前回ご紹介したようにInnoDB Pluginには以下の強化点がありますが、本日はこのうちバックグラウンドI/Oスレッドの増加に焦点を当ててみたいと思います。 高速なインデックス作成。従来InnoDBのCREATE INDEXはテーブルの再作成を伴っていました テーブルとインデックスの圧縮 (検証結果その1、その2) INFORMATION_SCHEMAによるロック競合の検出 (検証結果) CPUスケ
MySQL 5.1.38 リリース ＆ リリースノートの InnoDB Plugin に関する部分の超訳 - sakaikの日々雑感～(T)編
MySQL 5.1.38 がリリースされました。5.1シリーズはここ数ヶ月は毎月月初に必ずリリースされていて、MySQLリリース管理が安定したことを感じさせられます。 http://www.mysql.gr.jp/frame/modules/news/article.php?storyid=147 今回のリリースノートには、いつもの「変更点」の箇条書きだけでなく、今回のリリースから加えられた「InnoDB Plugin」についての説明が長々と書かれています。 英語は外国語にしか見えない私にとって（←当たり前だ）自分の理解のために例によって「超訳」してみました。 訳なんて言葉を使うとバチがあたりそうなので「私の理解を、なるべく原文の話の筋に沿って私の言葉で説明してみました」くらいの感じだと思って下さい。誤りや勘違いなどに気づいたかたは教えて下さい。 原文はここ：http://dev.mysq
MySQL 5.1.38リリース InnoDB Plugin追加！ - SH2の日記
出ました。今回は仕様変更が4件、バグ修正が49件あります。そのうちレプリケーション関連で仕様変更が1件とバグ修正が4件、パーティショニング関連でバグ修正が3件あります。 今回のリリースから、配布物になんとInnoDB Pluginが含まれるようになりました。もちろん従来のInnoDBストレージエンジンも残されており、選んで使えるようになっています。InnoDB Pluginのバージョンは1.0.4で、これはまだベータ版とされています。 従来のInnoDBストレージエンジンと比べて、InnoDB Pluginには以下の機能強化が施されています。このうちいくつかは本ブログでもすでにご紹介しているものです。 高速なインデックス作成。従来InnoDBのCREATE INDEXはテーブルの再作成を伴っていました テーブルとインデックスの圧縮 (検証結果その1、その2) INFORMATION_SCH
参照と更新が頻繁に発生するテーブルでMyISAMとInnoDBを比較 - cloned.log
[追記 2012/09/29] 最近でもこの記事を参照してくださる方がいるので追記します。下記エントリを書いた時点では非常に局所的なケースで重い現象に悩まされていたことを前提に調査しており、その延長線上で「一律InnoDBというのは言い過ぎな印象を受けるパフォーマンス差に感じる」ということを書いてしまっていますが、その後色々と勉強した結果、特定箇所のニッチなベンチマークではなく一般的な運用上の負荷を焦点にした場合はInnoDBは適切に設定しておれば十分にパフォーマンスがある（もしくはInnoDBの方が有利）というのが現在の意見です。 「MyISAM InnoDB」で検索するとあちらこちらであるように、今時は理由がなければInnoDB、ということでMyISAMのテーブルをいくつかInnoDBに変更したところ、かなりパフォーマンスが落ちるケースがあった。 InnoDBにしたら軒並み遅くなったと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Transactions on InnoDB » Blog Archive » Only God can make random selections
http://blog.flatlabs.net/20100727_212649/
AndroidのNFC機能でFeliCaの読み書きをする | −ゆめログ− | ゆめみスタッフブログ