MySQL 5.5の秘伝のタレが5.6では腐っていたはなし | GMOメディア エンジニアブログ
もう寒の入りを過ぎましたね。DBAのたなかです。 GAからもうすぐ1年、社内ではもう相当カジュアルにMySQL 5.6をインストールしています。今までは新規サービス(や、新規機能)での導入がほとんどだった5.6を、このたびトラフィックガンガンのサービスにアップグレードで導入しました（と、偉そうに言っていますが私でない別のDBA氏が主担当のサービスです） 主な理由はInnoDB Compressedを使っていたのでその性能アップに期待…というところだったんですが、弊社DBAが神代の時代より試行錯誤を重ねたどり着いた究極のmy.cnf(?)、いわゆる秘伝のタレが 残 念 な が ら 腐 っ て お り 夜を徹してアップグレード作業をしていた担当DBA氏が青い顔(推定。チャットだった)で ス ロ ー ク エ リ ー が 1 0 倍 く ら い に な っ た ん だ け ど … と訴え、彼はその
(帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ！この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている
【MySQL】AUTO_INCREMENTの値が戻る＠InnoDBエンジンのテーブル at softelメモ
MySQLサーバー再起動の場合 まずこれ。 サーバーが再起動すると、auto_incrementの値が select max(id)+1 になってしまう。 InnoDB は、ai_col を名づけた AUTO_INCREMENT カラムを含むテーブル T に自動インクリメント カウンタを初期化する為に、次のアルゴリズムを利用します:サーバの起動の後で、テーブル T への最初の挿入をする為に、InnoDB はこのステートメントと同等な物を実行します: SELECT MAX(ai_col) FROM T FOR UPDATE; （中略） InnoDB はサーバが起動している限り、メモリ内の自動インクリメント カウンタを利用します。サーバが停止し再起動した時、先ほど説明があったように、InnoDB は、テーブルへの最初の INSERT に対する各テーブルのカウンタを再初期化します。 http:/
MySQL InnoDBのネクストキーロック おさらい - SH2の日記
MySQLのInnoDBストレージエンジンは行ロックをサポートしています。しかしOracleと同じ感覚でアプリケーションを作っていると、思わぬところでデッドロックに出くわすことがあります。これはInnoDBのロック範囲がOracleよりも微妙に広いためです。 実際の例で確認してみましょう。 mysql> select * from t; +----+------+ | c1 | c2 | +----+------+ | 10 | a | | 15 | a | | 20 | a | | 25 | a | | 30 | a | | 35 | a | | 40 | a | | 45 | a | | 50 | a | +----+------+c1列は主キーになっています。1つめのセッションで以下のSQLを実行します。 mysql> set tx_isolation = 'repeatable-r
クエリキャッシュを切ったほうがいイカ？ ベンチマークしてみた - 酒日記 はてな支店
カジュアル！(挨拶) このエントリは MySQL Casual Advent Calendar 2011 の18日目の記事です。 昔、専ら PostgreSQL を使っていた頃、MySQL のクエリキャッシュって簡単に性能上がるしみたいだし羨ましいなあ、と思っていました。そのため、1年ほど前から業務で MySQL を使うようになっても、クエリキャッシュは当然のごとく有効にしておりました。 ところが先日 DSAS開発者の部屋:クエリキャッシュは切ったほうがいいんじゃなイカ？ というエントリを読みまして、クエリキャッシュはグローバルロックを獲得するとのこと。これはちょっと検証してみなければなるまい、ということでベンチマークをしてみました。 ベンチマーク結果 結果は別ページにまとめました benchmark script と my.cnf ざっくりと説明しますと、 平均 260 byte/行、1
転職等、状況のご報告
一部の関係者や、勘の鋭い方はお気づきだと思いますが、11月にPerconaを辞して、12月よりInnoDB teamの一員として働くこととなりました。XtraDB等Perconaの製品については少なくとも現職にある限りは、関与することは今後基本的にありません。 XtraDBは私にとっては、InnoDBという優れたアーキテクチャの持つポテンシャルを引き出す手段を素早く積極的に世に問うための重要なチャネルでした。しかし利用者が増えるに連れ、利用者や会社にとっては製品としての位置づけが強くなってしまったようです。この立場の違いが、開発の方針のあらゆる面での意見の相違を生んだと思います。迅速な進歩を失ってしまっては、永続的な存在意義は無いと、例え現在満足していても、将来問題に直面したときに小手先で解決できることなどもう無いのです、先に手を打たなければ。体裁を気にして将来の継続的なメンテナンスコスト
さらなる更新系処理の並列実行性の向上について
InnoDB性能フリークの皆様（日本語圏にいるかどうか解りませんが…）、ご無沙汰しております。MySQL-5.6では我々外野開発者が色々実装してきた改良・機能について人気の高い物・有効な物から順に積極的に取り込まれる様子が見て取れます。これはMySQLの開発コミュニティにとって素晴らしい進歩です。我々の活動が多くのユーザーに支持され、本家側からも無視できなくなり、何らかの進歩を阻害する要因が解決されたのではないでしょうか？感無量です。これで私も更に前へ進むことが出来るというものです。というわけで、今回は今まで誰も触れてこなかった問題に触れてみます。 InnoDB の更新系処理のスケーラビリティは、私が過去に数多のRDBMSをベンチマークした経験上、商用RDBMSと比べてまだ明らかに低い印象を受けます。この記事を読むような人は勿論InnoDBのmutex/rw_lockの競合状態の確認はでき
InnoDBロック競合の確認(MySQL 5.1+InnoDB Plugin, 5.5以降) | キムラデービーブログ
オープンソースデータベースを加速する「キムラデービー」のブログです。カレー日記を兼ねてます。なお著者は2010-06-01より日本オラクルに在籍していますが、本サイト（ブログ、またはウェブサイト）において示されている見解は、私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。 MySQL 5.1+InnoDB Plugin, 5.5以降でサポートされた以下の三つの情報スキーマテーブルを使うとトランザクションとロックに関わる情報をInnoDBロックモニタよりも簡単でわかりやすく取得することが可能です。 | INNODB_LOCK_WAITS |独自: ロック待ち情報 | INNODB_LOCKS |独自: ロック競合情報 | INNODB_TRX |独自: トランザクション情報 通常一つの接続ではトランザクションのBEGIN; COMMIT;を何度か行います。つまり一つ
BLACKHOLEストレージエンジンを使ってInnoDBなテーブルの暖気運転をする - （ひ）メモ
どうもこんにちは。小太り男子中年のサーバーエンジニアです。 先日行われたhbstudy#13の [twitter:@nippondanji]さんのセッション(スライド) で、「BLACKHOLEストレージエンジンを使えば、InnoDBなテーブルの暖気運転(テーブルデータを空読みして、buffer poolに乗っける)ができる」という話があったので、あなるほどーと思い試してみました。 CREATE TABLE _preload LIKE huge_table; ALTER TABLE _preload ENGINE = BLACKHOLE; INSERT INTO _preload SELECT * FROM huge_table; DROP TABLE _preload;なるほどなるほど。
InnoDB行ロック待ちの秒数をセッション単位で指定する[MySQL 5.1, MySQL 5.5の場合] | キムラデービーブログ
InnoDBの行ロック待ち時間は秒単位でinnodb_lock_wait_timeoutシステム変数に指定した時間待つ仕様になっていました。(デフォルトは50秒) ただMySQLではこの変数はグローバルでしか設定できず、一部のクエリのためだけにグローバル設定を変更するのはインパクトが大きく、特定の接続(セッション)やクエリ単位で設定できないかという機能要求があげられていました。 innodb_lock_wait_timeout is not dynamic, not per session ビルトインのInnoDBでは、この動作は変わりませんが、PluginのInnoDB(MySQL 5.1 + InnoDB Plugin 1.0, もしくはMySQL 5.5(InnoDB Plugin 1.1))では、innodb_lock_wait_timeoutにセッション単位のものが用意され、以下
How to Change innodb_log_file_size
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
Taking Advantage of MySQL Taking Advantage of MySQL Performance Improvements - marqs tech
最近のPerconaのプレゼン資料で参考になったところをいくつかピックアップinnodb_io_capacityとinnodb_[read|write]_io_threadsは今後はこれをベースに設定してみる。RAID10でディスク6本の場合はどうしたらいいのかな？あと、SSDの場合はinnodb_iocapacityはディスク本数x150よりもっと大きくしてよさそう。innodb_adaptive_checkpoint = estimateとinnodb_log_file_sizeも検証してみる。資料自体は、8/26に開催されたOracle Development Tools User GroupでBaron Schwartzが発表した内容らしい。資料urlTaking Advantage of MySQL Taking Advantage of MySQL Performance Im
ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門 広く浅くを担当してます、ota です。 技術ブログ第一回から早速流用スライドで申し訳ありませんが、社内勉強会資料として作成した「MySQL INDEX + EXPLAIN入門」です。 当社でもソーシャルゲームの開発を行っていますが、このような大量のデータを使用する・クエリの速度が求められる場合にインデックスは大変重要です。 インデックスの有効な利用にはDB設計者だけではなくプログラマにもある程度の知識が最低限必要となりますが、インデックスについての初心者向け資料があまりないようです。 このスライドではプログラマに知っておいて欲しい以下の基本的な点をまとめました。 INDEXを使用する時に気をつけること WHERE句 !=、<>はインデックスが使用できない WHERE句の全てのANDにかかっていないイン
知って得するInnoDBセカンダリインデックス活用術！
InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が
InnoDBのログとテーブルスペースの関係
InnoDBのデータ領域はログファイルとテーブルスペースという、切っても切れない2種類のファイルから構成されている。ログファイルは名前からするとただのログだから削除しても平気かな？と思って削除してしまうという問題が後を絶たない。そこで、今日はログファイルとテーブルスペースの関係について説明しようと思う。 InnoDBのログファイルは、別名WAL - Write Ahead Logと呼ばれるもので、名前を日本語に直すと「前もって書き込んでおくためのログ」とでも呼べるだろうか。InnoDBのテーブルに対して行われた更新は、全ていったんログに書き込まれるのである。トランザクションがコミットされると、innodb_flush_log_at_trx_commit=1が設定されていればログファイルに書き込みが行われる。0または2の場合には、ログバッファと呼ばれる領域にデータが保持される。その後、時間を
たった3秒でInnoDBのデータローディングが快適になるライフハック
MySQLに限った話ではないが、データベース管理システムに大量のデータを投入するのは時間が掛かり大変苦痛を伴う作業である。劇的に効能があるわけではないが、MySQLを利用しているとき、特にInnoDBを使っている場合にはデータの投入を高速化するためにいくつかテクニックがあるので紹介しよう。皆さんの作業時間が短縮され、少しでも早く帰路に着いたりサービスインさせたりという形でお役に立てれば幸いである。ちなみに、タイトルはネタであるのだが、もし本当に3秒で以下の全ての設定を行えた人が居たら教えて頂きたい！ ログファイルサイズの調整データ投入時に限った話ではないが、ログファイルサイズを調整するのは更新性能にとって非常に重要なファクターである。バッファプールのサイズが重要なことに代わりはないが、同じぐらいログファイルのサイズも重要である。InnoDBはログファイルを使い切ってしまうと、バッファプール
MyISAMとInnoDBのどちらを使うべきか
Twitterで話題になってたので簡単にまとめました。 ●MyISAMにしか無い機能を使いたい場合はMyISAMを使うしかない ・全文検索 (TritonnやSphinx) ・GIS ●InnoDBの利点(MyISAMの欠点) ▲障害対応系 ・クラッシュしても再起動するだけでリカバリができる ・クラッシュリカバリにかかる時間はテーブルサイズに比例するようなことはなく、コミット済みのデータは修復できる (巨大なMyISAMテーブルのREPAIRには数日単位で時間がかかることがある) ・オンラインバックアップができる ・INSERTやLOAD DATAなどを実行している途中でCtrl+Cでその更新系SQL文を止めても、テーブルは壊れないし、中途半端な状態で更新されることも無いし、スレーブが止まることも無い ▲性能系 ・行レベルロックなので並列性が高い(MyISAMはテーブルロック)。またSEL
参照と更新が頻繁に発生するテーブルでMyISAMとInnoDBを比較 - cloned.log
[追記 2012/09/29] 最近でもこの記事を参照してくださる方がいるので追記します。下記エントリを書いた時点では非常に局所的なケースで重い現象に悩まされていたことを前提に調査しており、その延長線上で「一律InnoDBというのは言い過ぎな印象を受けるパフォーマンス差に感じる」ということを書いてしまっていますが、その後色々と勉強した結果、特定箇所のニッチなベンチマークではなく一般的な運用上の負荷を焦点にした場合はInnoDBは適切に設定しておれば十分にパフォーマンスがある（もしくはInnoDBの方が有利）というのが現在の意見です。 「MyISAM InnoDB」で検索するとあちらこちらであるように、今時は理由がなければInnoDB、ということでMyISAMのテーブルをいくつかInnoDBに変更したところ、かなりパフォーマンスが落ちるケースがあった。 InnoDBにしたら軒並み遅くなったと
How to calculate a good InnoDB log file size
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InnoDBのプロは寡黙な紳士―木下靖文さん
