仕事でMySQLのパフォーマンスチューニングをしていて、インデックスについて分かっていないことが多かったので調べたことをメモ。基本的なところから学習しなおした。 MySQLのインデックスは、カラムが特定の値をもつレコードの迅速な検索に使用される。インデックスを使用すれば、数百とか数億ものレコードが入っているテーブルから、一組のレコードを迅速に見つけて取り出すことが可能になる。 しかし、インデックスは速度を改善することもあるが、挿入の邪魔になって遅くなることもある。 インデックスを適切に使うために、まずはインデックスの基本概念をおさえる必要がある。 インデックスの概念 インデックスとは インデックスの仕組みを理解するには、まずMySQLがどのようにクエリに応答するかを知る必要がある。 例えば、 SELECT * FROM phone_book WHERE last_name = 'Hoge'
インストール記事では、Postgresql にインストールしているのに、いきなりMysqlになっているのは、顧客のシステムでの話を後追い調査してみたから。 ■環境 ２０台程度のFreeBSDサーバと１５台程度のLinux(Redhat系)サーバを監視しているzabbixサーバがある。zabbixサーバのメモリは384MBで15GBのHDDを持つ（仮想サーバで運用しているため。） ■現象 zabbixサーバのディスク使用量が運用開始一か月後に90％を超えてしまった。 どの領域が肥大化しているかを調査すると、/var/lib/mysql/ibdata1 というファイルだった。 このibdata1はMysqlのinnodbが共有ディスク領域として使用しているファイル。 ■調査内容 ibdata1が肥大するタイミングは不定期。 1時間ぐらい同じサイズだったのにいきなり7MBほど増えたりする。 スク
前回、推測したibdata1が膨らむ理由にて考えたので もうちょっと調べてみることにした。 http://nippondanji.blogspot.com/2010/03/innodb.html 漢(オトコ)のコンピュータ道: たった3秒でInnoDBのデータローディングが快適になるライフハック http://mysql41.man.hive0.net/r/table-types.html#implementation 7.5.11. マルチバージョニングの実装 http://www.interdb.jp/techinfo/mysql/m-2-08.html MySQLとは: ■2-08■ InnoDB型 これらの情報をみると、ロールバックセグメントにはUPDATEのUNDO領域（読み取り一貫性にも使用）とINSERTのUNDO領域があるらしい。 特に、僕の遭遇した「スクリーンなどのグラフ
MySQLに限った話ではないが、データベース管理システムに大量のデータを投入するのは時間が掛かり大変苦痛を伴う作業である。劇的に効能があるわけではないが、MySQLを利用しているとき、特にInnoDBを使っている場合にはデータの投入を高速化するためにいくつかテクニックがあるので紹介しよう。皆さんの作業時間が短縮され、少しでも早く帰路に着いたりサービスインさせたりという形でお役に立てれば幸いである。ちなみに、タイトルはネタであるのだが、もし本当に3秒で以下の全ての設定を行えた人が居たら教えて頂きたい！ ログファイルサイズの調整データ投入時に限った話ではないが、ログファイルサイズを調整するのは更新性能にとって非常に重要なファクターである。バッファプールのサイズが重要なことに代わりはないが、同じぐらいログファイルのサイズも重要である。InnoDBはログファイルを使い切ってしまうと、バッファプール
mysqldump を 使用してバックアップを取得したファイルを開いてみると ビュー（view）などの箇所に /*!50001 DROP TABLE `v_test`*/; などの特殊？なコメントで囲まれたところがあったりします。 コメントになってると復元する際にコメントをチマチマ取り除く必要があるのかと思い、コメントが付かないように出力できないか調べてみてみたんですが、これはこれで意味のあるコメントらしいです。 /*!50001 この数字はMySQLのバージョン番号を意味しているようで、MySQLのバージョンが等しいか大きい場合にのみ実行されます。 （この場合 5.00.01 以上であれば実行されます） MySQLはバージョン毎に拡張されている機能が異なるため、バージョンが異なるデータ移行が可能となるように特殊なコメントを付加しているようです。 当然、MySQLのバージョンを下げる場合や
まず、消してよいログの確認 mysql> show processlist; 以下のような行があれば、 Binlog Dump | 6007623 | Has sent all binlog to slave; waiting for binlog to be updated レプリケーション先が存在するので、その行の「 Host 」 に接続し、 mysql> show slave status\G で Master_Log_File: mysql-bin.001295 マスターログのファイル番号を確認。 （この例だと mysql-bin.001294 までは完了しているということになる） mysql> purge master logs to 'mysql-bin.001294'; mysql-bin.001294 までのログを削除 日付指定で実行したい場合は以下。 mysql> pur
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く