やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
MySQLでランダムにレコードをselectする。パフォーマンス対策３つ。 - mtomizの日記
例えばMySQLのデータベースからWEBサイト上にランダムに商品情報や広告情報を取得して、１０件程度表示させたいとする。単純に、SELECT * FROM table ORDER BY RAND();を使用することが考えられるが、ランダム取得すると全件取得と同じ負荷がかかるので、データ件数が数万件以上あるような場合処理パフォーマンスが問題となる。したがって、SELECT * FROM table ORDER BY RAND() limit 0, 10;として１０件ランダムに取得しようとしても全件取得相当の処理パフォーマンスとなり実用的ではない。【対策】１．取得するカラムが少ないのであれば＊ではなくselect id,name,price from table order by rand() limit 0,10; などとするとかなり早い２．ランダムに”切り取る”ことができれば１０件は連続し
Rubyisms | MySQL-dump
Lately, I have had opportunity to evaluate a very large Ruby installation that also was growing very quickly. A lot of the work performed on site has been specific to the site, but other observations are true for the platform no matter what is being done on it. This article is about Ruby On Rails and its interaction with MySQL in general. Com_show_fields as a RoR indicator (and not cached enough?)
Kazuho@Cybozu Labs: MySQL のクエリ最適化における、もうひとつの検証方法
« メッセージキュー事始め with Q4M | メイン | フレンド・タイムライン処理の原理と実践 » 2008年06月09日 MySQL のクエリ最適化における、もうひとつの検証方法 EXPLAIN を使用して MySQL の SQL を最適化するというのは、良く知られた手法だと思います。しかし、EXPLAIN の返す結果が、かならずしもアテになるわけではありません。たとえば、以下のような EXPLAIN を見て、このクエリが最適かどうか、判断ができるでしょうか。私には分かりません。 mysql> EXPLAIN SELECT message.id,message.user_id,message.body FROM message INNER JOIN mailbox ON message.id=mailbox.message_id WHERE mailbox.user_id=2 OR
Nix::WebLab: my.cnf 変更後に MySQL が起動しない
InnoDB で運用していて、MySQLをチューニングしたい場合、大抵は my.cnf の innodb_* の値を変更しますよね。でも innodb_log_file_size に変更を加えたら MySQL が起動しなくなってドキッとした経験はありませんか？（自分だけか？） InnoDB: Error: log file /usr/local/mysql/var/ib_logfile0 is of different size 0 5242880 bytes InnoDB: than specified in the .cnf file 0 104857600 bytes! 070301 23:26:07 Can't init databases 070301 23:26:07 Aborting 要はサイズが違うじゃないですか、ということなので、 mv ib_logfile0 ___ib
mysqlコマンドで、テーブル名とかカラム名の補完(completion)をする方法 - (ひ)メモ
追記: rehash(auto-rehashも含む)すると、SQL文の補完(seleでタブ打鍵とか)が効かなくなるよと、はす向かいの人に教えてもらいました。 個人的には、SQLは「mysql> help select」とかでオンラインヘルプがびょっと出るので、スキーマの補完ができるんならSQLの補完はとりあえずあきらめてもいいかなと思っています。 常々、テーブル名とか補完できるといいなーと思っていたので、ボロっときいてみたら教えてもらいました。あざーーーーっす！ id:mikihoshi++ id:tokuhirom++ id:precuredaisuki++ おかげで効率が300%上がりました。(Benchmark::Stopwatchで計測) http://dev.mysql.com/doc/refman/5.1/en/mysql-command-options.html#option
ウノウラボ Unoh Labs: MySQL オペミスでデータが破損してしまった場合の復旧方法
こんにちは satoです。 オペミスで update に where句を付け忘れたり、プログラムのバグでデータが破損してしまったりした場合でも、バイナリログには更新SQLがすべて書き込まれるので、バックアップデータからオペミスが起こるまでの全てのSQLを流し込めれば、元の状態に戻すことは可能です。 •バイナリログを取っている •オンラインバックアップをとっている(mysqldumpやMySQLを止めた状態でのcpによるバックアップとバイナリログ) •バックアップ時点でのバイナリログの書き込み位置を保存している 以上のような状態でデータが壊れた時の復旧手順をまとめてみました。シナリオとして •ある1カラム email をupdateしようとしたら、間違ってwhere 句を付け忘れ 全レコードをupdateしてしまった •気がついたのが半日後 というオペミスが発生したとします 1) データベー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
