MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ！この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている

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

データベースの運用で避けられないのが、ロック競合によって起こるシステムトラブルへの対応です。「2時までに終わるはずのバッチ処理が朝になっても終わっていない」とか「負荷が高いわけでもないのにシステムが無応答になっている」といったトラブルが発生したとき、DBエンジニアはそれがロック競合によるものなのかどうかを切り分けて、適切に対処しなければなりません。 これまでInnoDBはロック競合に対してほとんど打つ手がなかったのですが、最近ようやく対処方法がでてきました。今日はその手順を確認していきたいと思います。 前提 今回ご紹介する手順は、MySQLの以下のバージョンを対象にしています。 MySQL 5.1＋InnoDB Plugin 1.0 MySQL 5.4 いきなりハードルを上げてしまって申し訳ありませんが、バージョン5.0以下や素の5.1では使えませんのでご注意ください。以降の実行例はすべて

今年も残すところあとわずかとなった。2010年もIT業界にとっては変化の多い一年だったが、皆さんにとっては良い年だっただろうか？既に何度かMySQL 5.5の新機能については取り上げたが、ついに正式版がリリースされたということでここで改めて新機能を解説し、今年最後のエントリを締めくくろうと思う。 MySQL 5.5にはこれでもかっ！というぐらい新機能が追加されている。しかもいずれもナイスなものばかりだ。一般的には、ソフトウェアに新機能が追加されると重くなったり安定性が低下する事例が後を絶たないのだが、MySQL 5.5に関してはそのようなことは全くないので安心して利用して頂きたい！ InnoDBの大幅な改善種々ある改善点の中でも特に目をひくのがInnoDBストレージエンジンへの改良だ。実は、InnoDBはMySQL 5.1が最初にリリースされたときから、2回アップデートが行われている。My

InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T

はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

MySQLに限った話ではないが、データベース管理システムに大量のデータを投入するのは時間が掛かり大変苦痛を伴う作業である。劇的に効能があるわけではないが、MySQLを利用しているとき、特にInnoDBを使っている場合にはデータの投入を高速化するためにいくつかテクニックがあるので紹介しよう。皆さんの作業時間が短縮され、少しでも早く帰路に着いたりサービスインさせたりという形でお役に立てれば幸いである。ちなみに、タイトルはネタであるのだが、もし本当に3秒で以下の全ての設定を行えた人が居たら教えて頂きたい！ ログファイルサイズの調整データ投入時に限った話ではないが、ログファイルサイズを調整するのは更新性能にとって非常に重要なファクターである。バッファプールのサイズが重要なことに代わりはないが、同じぐらいログファイルのサイズも重要である。InnoDBはログファイルを使い切ってしまうと、バッファプール

巷ではプログラミング言語の最速マスターが流行ってるので、MySQLも参戦。ただし管理者向け。 まずはダウンロードとインストールダウンロードサイト http://dev.mysql.com/downloads/ バイナリにはインストールパッケージ（Windows=MSI、Mac=DMG、Linux=RPMとか）とアーカイブ（*NIX=tar.gz/Windows=zip）があるけど、初心者は黙ってパッケージをチョイス。インストールはウィザードに従うだけ。英語だけどそこはガマン！ パッケージリポジトリがあるOSを使ってるなら、リポジトリからインストールするのもありだ。例えば、 shell> sudo yum install mysqlとか shell$gt; sudo apt-get install mysqlとか。これは楽チンだけどMySQLのバージョンがちょっと古くなるので注意。 もちろん

スナップショットを使えばとある瞬間のディスクやファイルシステムのデータをいつでも後から参照することができる。しかもスナップショットの作成は一瞬だ。スナップショット機能を活用すれば最強のオンラインバックアップソリューションが出来るだろう。 しかし、スナップショットでバックアップを取るなんて危険な操作じゃないのか？！と不安に思われる方もいらっしゃるかも知れない。MySQL Serverが稼働中にいきなりデータだけをとってくるのだから、そのような疑問を持たれるのは頷ける。しかし仕組みさえ分かればスナップショットによるバックアップは怖くないということが分かるはずだ。そこで、まずはスナップショットによるバックアップの仕組みについて説明する。スナップショットを取る際の要件は次の通りである。 全てのデータを単一のボリュームに置くこと。つまり、一回のスナップショット操作でバックアップが取れることだ。 ディ

実験エントリです。 予習してみる 「転置インデックス」というキーワードで検索して、しばらく勉強してみます。 転置インデックス - Wikipedia mixi Engineers’ Blog » 転置インデックスを実装しよう ASCII.jp：悟空、秘剣「転置インデックス」を手に入れる ｜Googleはなぜ的確に探せるのか？ [を] 転置インデックスによる検索システムを作ってみよう！ 転置インデックスで学ぶ検索エンジンの中身アプリ - 睡眠不足？！ うーんなるほど。分かったような分からないような。 作ってみる とりあえず、Twitter4Jを使ってこんなデータを用意しました。ちなみに人選は漢(オトコ)のコンピュータ道: MySQLerのTwitterアカウントまとめ。を参考にさせていただきました。 5707049458,2009-11-14 20:28:34,sakaik,@hbstudy

InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー

日本時間の今日、InnoDB Pluginの新バージョン1.0.4がリリースされました。このバージョンでは、「バイナリログを有効にするとグループコミットが効かなくなる問題」が修正されています。ほとんどの環境にとって極めて効果の高い修正です。ほかにもI/Oスレッドの多重化(同様のものがMySQL5.4にも搭載)など効果的な修正が行なわれています。 InnoDB PluginはまだGA(安定版)ではないので、品質面では標準搭載されているInnoDBよりも落ちます。ただしMySQL Enterpriseサブスクリプションを買っている方であれば追加費用無しでInnoDB Pluginのサポートを受けることができるので、お気軽に試してみて頂ければと思います。 グループコミット問題修復の効果のほどは、一目瞭然なので図を見た方が分かりやすいでしょう。下図は、mysqlslapで、複数のコネクションから並

MySQLを使い始めて間もない人がよく陥る罠の中に、気づくと使ってるストレージエンジンがMyISAMだった！ということがある。デフォルトのストレージエンジンはMyISAMなので、MySQLに詳しくない人たちが比較的陥りやすい罠なのだ。そもそもストレージエンジンという概念自体がMySQL独自のものなので仕方のない話である。MyISAMは素晴らしいストレージエンジン（たとえばこのYahoo!の中の人による投稿で言われているように）であるが、長所もあれば短所もある。例えば、 トランザクション対応ではない。 クラッシュセーフではない。 更新と参照が入り乱れた場合の同時実行性能がよくない。 テーブルが大きく（数億行とか）なるとINSERTの性能が劣化する。 などなど。特に前者の2つが問題で、アトミックな操作が必要なところでロジックを実装出来なかったり、サーバがクラッシュした時にデータがお亡くなりにな

以前の投稿でも書いたが、InnoDBのテーブルスペースは一度大きくなってしまうと縮小することができない。ならば実際にはどれだけのスペースが使われているのか？という疑問が沸いてくることだろう。それは、innodb_file_per_tableオプションを利用しているときとそうでないときで見方が違う。 innodb_file_per_tableオプションを利用していない場合には、InnoDBテーブルスペース内の空き領域は、SHOW TABLE STATUSコマンドで確認することができる。 mysql> SHOW TABLE STATUS LIKE 'tbl'; MySQL 5.0または5.1.23以前ではCommentフィールドに、MySQL 5.1.24以降ではData_freeフィールドに空き領域の容量が表示される。MySQL 5.1のGAバージョンは5.1.30なので、実質的には「5.1

この記事をブックマークする : こんにちはタガヤです。 いろいろとキャリアを積んだボクでも、日々勉強することがたくさんあります。 それだけ問題が起きてるってことですけども。 いやー、トラブルシューティングって楽しいですｗ（ドMか？） さて今回見舞われたトラブルですが、 VineLinux4.2 に Tritonn をRPMでインストールして使ってます。 トランザクションが大目のテーブルには、InnoDBを使おうと思ったら、 InnoDBでCreateしても、作成されるテーブルはMyISAMになってしまいます。 mysql > SHOW INNODB STATUS; するとエラーメッセージが表示されます。 ERROR 1235 (42000): Cannot call SHOW INNODB STATUS because skip-innodb is defined skip-innodb