[B! database] nyomonyomoのブックマーク

MySQLバックアップ頂上決戦！！ LVMスナップショット vs InnoDB Hot Backup

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

nyomonyomo 2009/12/23

リンク

限界までMySQLを使い尽くす!!

どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。データベースの個数データベースオブジェクトの個数に制限はない。データベースオブジェクトは

nyomonyomo 2009/05/19

SQL文の最大長とかテーブル数とか

リンク

「郵便番号データの落とし穴」に落ちてしまいました。 - 日記

いま、仕事で郵便番号のデータをデータベースのテーブルに登録するツールを作成している。登録するデータは日本郵便のサイトからダウンロードしてきたファイル(いわゆるKEN_ALL.CSV)を使用している。最初は毎月1回、自動でダウンロード圧縮ファイルを解凍システムが必要とする項目だけを抜き出して別のCSVファイルに落としシェルか何かで適当にテーブルにインポートと思っていたが・・・。ダウンロードするのはいいが、ファイルのダウンロードが成功したか、途中で失敗したかどうやって判定したらいいのかわからない。md5のファイルなどが別途用意されていればいいが、当然、日本郵便はそんな細かい仕事はやってくれない。圧縮の形式がLZHはいかがなものか。zipじゃだめなの？データフォーマットがひどい。KEN_ALL.CSVのデータフォーマットのひどさについては、郵便番号データの落とし穴を参照なのだが、問題は

nyomonyomo 2009/05/15

リンク

MySQLのEXPLAINを徹底解説!!

以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ