これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編） こんにちは、インフラ担当新人の nob です。 サーバー監視ツールで MySQL を監視しているのにデータが多すぎて活用していない。という方はいませんか？その豊富なデータをパフォーマンス・チューニングに活用しない手はありません。今回はサーバー監視ツールのグラフを読み解いた実戦経験を元に、「これだけ見れば大丈夫」というツボをまとめてみました。 これだけ見れば大丈夫！ クエリ編 ３つのつぼと５つのグラフ （その１）監視ツールが何を見ているのか知る （その２）監視のキモ、グラフ３点セット (Questions, Lock Waits と Transaction Handler) （その３）グラフでチェックする SQL チューニング ( Select Type と Handler) シンプルでお勧め、サーバー監視グラフ化ツール
myhome.munetika.mydns.jp is not accessible... Sorry. I do not know why this site is not working. If you know Administrator of this site, please contact directly. You may be able to see it in Google cache. For administrator ... MyDNS.JP did not received IP address from you over One week. Please check your notify system. If you restart notification of IP address, MyDNS.JP will apply your IP address
のように、全体件数と表示中のデータ件数が併記される場合が多い。ところが、レコード数が多くなったり、SQL文が複雑になると、全体件数の取得にかかるスピードが物凄く遅くなる場合がある。 と言う訳で、どのような方法で全体件数を取得するのが高速なのかを調べてみた。 環境はMysql+PHP。候補は次の３つ。 COUNTを使う。 mysql_num_rowsを使う。（*ＰＨＰ関数） FOUND_ROWSとSQL_CALC_FOUND_ROWSを使う。 サンプル ※以下のSQLの結果、及び、LIMITの制約を外した場合の結果（＝全体件数）を取得する。 $query = 'SELECT id, name, area FROM company ORDER BY id LIMIT 20'; $q1 = 'SELECT COUNT(*) FROM company'; //全体件数を取得するシンプルなSQLクエ
このドキュメントは最近メンテされていない項目が数多くあります。 リンクが切れていたり、現状のmysqlでは直っていたり、変更されている可能性が多々。 その点だけ注意して下さい。 InnoDBへ移行する際に把握しておかなくてはいけない事affected_rowsは英語で「影響を受けた行数」という意味疑似csv形式で出力するソースからの構築時のトラブルなんかよく分からないけどmysqlが重い時mysql_use_result()とmysql_store_result()の違いSHOW TABLE STATUS;my.cnfDBのエンコーディングとVARCHAR(n)の関係リファレンスレプリケーション一行だけmysqldumpするテーブルが破損した時にmysqlをとめずにバックアップを取る場合のパターンなんかよく分からないけどエラーが出た時テーブルの構造を、CREATE TABLEフォーマットで
ここのところ、javaccとawsに魅了されている米林です。 よく使うDB(Oracle/MySQL/PostgreSQL/SQLServer)における設計時のサイズ見積もりで使うサイトの備忘録。 あとは、OracleからのPython情報。 Oracle Oracle 物理設計 http://www.oracle.com/technology/global/jp/columns/skillup/oracle9i/index.html 領域サイズ見積もり http://otn.oracle.co.jp/document/estimate/index.html OTNにログインする必要ありますがオンラインで見積もりが出来ます。 アカウント持っていない人は、この見積もりツールを使う目的でアカウントを作ってみてはいかがでしょうか。 OLTP系とDWH系においてブロックサイズを考慮し、DWH系はブ
先日大きめ(といっても500万行くらい)のテーブルにインデックス付きのカラムを追加しようとして痛い目にあったので調査。 大きめのテーブルにカラムやインデックスを追加するとどうなるか 今回は単純に、「ALTER TABLE 〜 」で追加しようとしました。追加するカラムは3つで、 varchar(255) インデックスなし varchar(255) ↓のdate 型カラムとマルチカラムインデックスの形式のユニークインデックスあり date インデックスあり SQL を実行し、状況を「SHOW PROCESSLIST」で監視していたら、1つ目のカラム追加で次のような状態に… 最初にState が「copy to tmp table」状態になり、次の状態に遷移するまで1時間かかる 次にState が「Repair with keycache」状態になり、完了までに1時間かかる 次のカラム追加に対す
すぐに思いつく、オンラインバックアップの方法とおおまかな特徴です。 他にも方法があるかも知れません。 ご参考まで。 InnoDBの場合； １．レプリケーション 別途HWリソースが必要（別サーバ、または同一サーバに構成可能） リストアはデータファイルのコピーで完了→はやい ２．mysqldumpをsingle-transactionオプションつきで実行 整合性あるバックアップを取得可能 INSERT文を生成させるので、リストアに時間がかかる ３．商用ソフト http://www.innodb.com/hot-backup/ http://www.zmanda.com/press-release-zrm-mysql.html http://www.bakbone.co.jp/products/netvault.html http://www.networld.co.jp/ca/arc_line
今回は、MySQLのストレージエンジンの中でも特に有名な「MyISAM」と「InnoDB」の2つを取り上げます。MyISAMはMySQLのデフォルトストレージエンジンで、ストレージエンジンを指定せずにテーブルを作成するとMyISAMが選択されます。もう一方のInnoDBエンジンは、MySQLに豊富なトランザクション機能を提供するストレージエンジンとして有名です。 まずはそれぞれのテーブルファイルの構造について解説し、最後にInnoDBのトランザクションについて解説します。 各ストレージエンジンのファイル構造を説明する前に、前知識としてMySQLのディレクトリ構造について説明します。 MySQLのデータベースディレクトリには、バイナリログと呼ぶデータベースの更新情報を格納するファイルと、2つのサブディレクトリが存在します（図1）。 「mysql」ディレクトリには権限テーブルと呼ばれるMySQ
mysql のスレーブサーバで、show slave status を実行して、Slave_IO_Running が No で、Slave_SQL_Running が Yes になっている場合の対処法です。 mysql> stop slave; mysql> reset slave; mysql> start slave; スレーブサーバの状態を表示。 mysql> show slave status; これで Slave_IO_Running、Slave_SQL_Running ともに Yes となればＯＫ。 No なら、「mysqlのレプリケーションが止まったら」の方法でスレーブサーバのデータを再構築しましょう。
今日もまた mysql のマスターサーバのディスクがあふれて、レプリケーションが止まってしまいました。 こんなときは他の人はどのように対処しているのでしょうか？ 初めてこんな事態に陥ったときには、かなりあせったのですが、今となっては慣れたもんです。 1. スレーブでレプリケーションされている DB を削除 # mysql > stop slave; # mysqladmin drop *DB* # mysqladmin shutdown # mysqld_safe& # mysql > stop slave; 2. データのコピー マスターにて # mysql > show master status; スレーブにて > change master to master_log_file = 'HOST-bin.XXXX', master_log_pos = XXXX; > load dat
一部のリリースでは、権限テーブル（mysql データベース内のテーブル）の構造が変更され、新しい権限または機能が追加されています。新しいバージョンの MySQL に更新したときに権限テーブルが確実に最新のものであるようにするには、権限テーブルも更新する必要があります。 Unix システムまたは Unix ライクなシステムでは、以下のように mysql_fix_privilege_tables スクリプトを実行して権限テーブルを更新します。 shell> mysql_fix_privilege_tables このスクリプトは、サーバの稼動中に実行しなければなりません。このスクリプトは、ローカルホスト上で稼動しているサーバに root として接続します。 root アカウントがパスワードを必要とする場合は、コマンドラインでパスワードを指定します。MySQL 4.1 以降のバージョンの場合は、以
元ネタ: http://labs.unoh.net/2007/07/mysqltips.html あまり具体的じゃないので、僕の考えとか。 正しいかどうかは各自の状況だとか実際試すべきなんだけど、参考になれば。 MyISAM、InnoDBなどテーブルタイプ 僕は断然InnoDB派です。 ただ仰るとおり、ログるだけのテーブルとかならMyISAMでもいいとは思うけど。 トランザクションやロック処理などが必要ない場合など、MyISAM形式にも良いところはあるので検討してみる価値はあるかもしれません。 これだけの指摘だとちょっと微妙な気がするです。 MyISAMの使いどころってのは、 ピンで他とリレーションが無い単純追記系のテーブル リレーションがあり、同一トランザクション内での更新系クエリが存在する場合は、トランザクションが期待通りに動かないので、基本的にはInnoDBと混在させるべきではない
データベースは，大量のデータを格納して目的に合わせて処理するのが役割である。処理を高速化する機能として，インデックスが用意されている。インデックスは，あらかじめ検索やソート対象となる列のデータを処理しやすいように別管理するものだ。インデックスを使いこなせるかどうかで，データベース処理の良し悪し決まるといっても過言ではない。しかし，インデックスいつまでも高速ではない。その効果が，色褪せる時がやってくるのだ。 インデックスの効用 まずは，肩慣らしにインデックスの効用を確認する。テーブル「pono」は，日本郵政グループの日本郵便事業株式会社が提供している郵便番号データを格納したテーブルだ。 図1●テスト用のテーブル「pono」 mysql> show create table pono \G *************************** 1. row *****************
完成形を見てしまった気がする。それくらいできが良い。 これまでWikiエンジンを幾つも紹介してきた。もちろん、機能面ではもの凄く充実しているものも数多い。だが、使い勝手や初期状態での機能等を考えると、これがまさに完成系と言えるのではないだろうか。 今回紹介するオープンソース・ソフトウェアはMindTouch Deki Wiki、エンタープライズ向けのWikiエンジンだ。 欠点がなさすぎる。日本語はもちろんOK、Ajaxを使って遷移の少ない作り、履歴管理＋差分表示にももちろん対応している。編集はWYSIWYGなテキストエリアでできる。 ヘッダを作れば、その中だけで編集できる。画像をアップロードして、埋め込むのも簡単。ページの階層管理もできて、タグも使える。ウォッチリストに登録、コメントをする、RSS配信など何でもござれだ。 さらに多言語対応、Google Analyticsを埋め込めるなどな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
