Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
MySQL 5.1のmysqldumpslowで快速チューニング - SH2の日記
MySQL 5.1のmysqldumpslowを使うとチューニングが楽になる！という話題です。 mysqldumpslowはもともとMySQLに付属しているツールで、スロークエリログを集計してくれるものです。これ自体はMySQL 5.1で特に変わったところはありませんが、スロークエリログ本体の方が機能強化されているため、組み合わせるとなかなか便利になっています。MySQL 5.1におけるスロークエリログの主な機能強化は以下の三点です。 long_query_timeに1秒未満の値を設定できるようになった。 出力先を設定できるようになった。 これらの設定をオンラインで変更できるようになった。 これでどうなるかというと、MySQLの性能分析をしたいと思ったときに、サーバを止めずにその場で mysql> set global slow_query_log = 1; mysql> set glob
blog.maru.cc - MySQLでのdump復旧 2時間が 6分に！
稼動中のサービスのDB操作。 これほど嫌なことは無い と思ってしまった。 スタートして1ヶ月ほどの auのとある公式サイトなのですが FOMA版がそろそろスタートするので 統合したシステムにするために少しDBを変更する必要がありました。 カラム追加でalterしたり テーブル追加でcreateしたり データ追加でinsertしたり データ変更でupdateしたり etc… もちろんテスト環境で何度も確認してるんだけど 万が一問題があった場合に dumpデータを復旧しなければならない。 胃が痛いのはその復旧時間。 テストサーバで試したら2時間以上かかる。 無停止で、せめて数分でという状況で2時間は痛すぎる。 ちなみにMySQLのInnoDBね MyISAMならば、DB自体をリネームしちゃうって手もあるんだけど そーもいかない。 社内の人たちにいろいろ聞き込み調査を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
