ここでは、EC2の上でinnodbをチューニングして使うという観点でTIPSをまとめてみた。 RDS便利だから使おうぜってのは今回の話のスコープには含みません。 あと、innodbについて、割りとちゃんと調べてみたのは初めてだったりするので、間違ってる点など見つけたらぜひご指摘くださいませ。 innodb関連 バッファプール ワーキングセットを乗せておくオンメモリのバッファ領域。読み書き共にこの領域を経由して実施される。 参照時はバッファプール上でデータを探して、なければテーブルスペースから取得する。（そのデータはバッファプール上に格納される） 書き込み時はリクエストを受け付けてワーキングセットを更新し、ログの書き込みへ移行する。 設定はinnodb_buffer_pool_size 監視はSHOW ENGINE INNODB STATUSか、mysqladmin extended-sta
MySQL PerfBlogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ！この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている
知られざるinnodb_flush_methodの値
innodb_flush_methodの値といえば、fdatasync(暗黙のデフォルト)かO_DIRECTくらいしか知らなかった訳だが、O_DSYNCやO_DIRECT_NO_FSYNC(5.6.7から)もあったり、Percona ServerにはALL_O_DIRECTなんてものがあったりする。 ⇒http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_flush_method ⇒http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_flush_method ⇒http://www.percona.com/doc/percona-server/5.1/scalability/innodb_io.
ロック読み取り (SELECT ... FOR UPDATE および SELECT ... LOCK IN SHARE MODE)
innoMySQLの状態をDBを1台ずつ見ていくぶんには特に使う必要性を感じなかったのですが、 サーバのグルーピング＆一括表示機能があることを知ってこれはけっこう便利なのでは？と思いなおしたので インストールからグループ設定までについて書いてみます。 サンプルイメージ グループ単位でクエリーリストを表示 グループ単位でレプリケーション状態を表示 インストール ここからダウンロードしてインストールします。 ※今回使ったのはinnoperl-DBI perl-DBD-mysql # rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-4.noarch.r
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の5日目です。 @methane による MySQL を骨までしゃぶるチューニングシリーズ (シリーズ名は今考えました)のまとめとして、現在の DSAS for Social の MySQL のリアルな性能値や直面しているボトルネックを赤裸々に公開 してしまいます。 innodb_io_capacity を増やそう 本題に入る前に、まだ紹介してないけど1記事にするほどではなかった パラメータを紹介しておきます。 innodb_io_capacity は、 InnoDB に教えるヒントで、 Disk の IO/sec を指定します。 デフォルトでは、通常のHDDでも使えるように中途半端な値(バージョンによって100か200) になっているのですが、BBU付きバッファがあるRAIDカードを使うな
オープンソースデータベースを加速する「キムラデービー」のブログです。カレー日記を兼ねてます。なお著者は2010-06-01より日本オラクルに在籍していますが、本サイト（ブログ、またはウェブサイト）において示されている見解は、私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。 MySQL 5.1+InnoDB Plugin, 5.5以降でサポートされた以下の三つの情報スキーマテーブルを使うとトランザクションとロックに関わる情報をInnoDBロックモニタよりも簡単でわかりやすく取得することが可能です。 | INNODB_LOCK_WAITS |独自: ロック待ち情報 | INNODB_LOCKS |独自: ロック競合情報 | INNODB_TRX |独自: トランザクション情報 通常一つの接続ではトランザクションのBEGIN; COMMIT;を何度か行います。つまり一つ
環境: MySQL 5.0 （マニュアルを見る限りバージョン5.1でも事情は同じ） 某CMSにて、1つのテーブルにGot DBの行サイズの上限はページサイズの約半分で、デフォルトでは約8000バイト 可変長カラム(VARBINARY, VARCHAR, BLOB,
MySQL 5.5新機能徹底解説
今年も残すところあとわずかとなった。2010年もIT業界にとっては変化の多い一年だったが、皆さんにとっては良い年だっただろうか？既に何度かMySQL 5.5の新機能については取り上げたが、ついに正式版がリリースされたということでここで改めて新機能を解説し、今年最後のエントリを締めくくろうと思う。 MySQL 5.5にはこれでもかっ！というぐらい新機能が追加されている。しかもいずれもナイスなものばかりだ。一般的には、ソフトウェアに新機能が追加されると重くなったり安定性が低下する事例が後を絶たないのだが、MySQL 5.5に関してはそのようなことは全くないので安心して利用して頂きたい！ InnoDBの大幅な改善種々ある改善点の中でも特に目をひくのがInnoDBストレージエンジンへの改良だ。実は、InnoDBはMySQL 5.1が最初にリリースされたときから、2回アップデートが行われている。My
知って得するInnoDBセカンダリインデックス活用術！
InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が
大人のためのInnoDBテーブルとの正しい付き合い方。
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
I guess note number one about MyISAM to Innodb migration is warning what Innodb is very slow in COUNT(*) queries. The part which I often however see omitted is fact it only applies to COUNT(*) queries without WHERE clause. So if you have query like SELECT COUNT(*) FROM USER It will be much faster for MyISAM (MEMORY and some others) tables because they would ble
There is significant portion of customers which are still using MyISAM when they come to us, so one of the big questions is when it is feasible to move to Innodb and when staying on MyISAM is prefdb as the main storage engine because it makes life much ith recovering tables on the crash or partially e
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.mysqlperformanceblog.com/wp-content/uploads/2010/04/InnoDB_int.png
