MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
GitHub - tokuhirom/optimize-perl-doc: how to optimize your perl code?
=head1 概要 本プロジェクトでは、Perl programming における、パフォーマンスチューニングの要諦について書く。 =head2 チューニングの原則 可読性/メンテナンス性とのトレードオフを意識し、メンテナンス性の低下をひきおこすようなチューニングは気をつけておこなうこと。 =head2 無根拠なチューニングはしない マイクロオプティマイゼーションにおいて、ベンチマーク結果のみにたよったチューニングはできるだけ避け、「どうしてこちらの方が高速なのか」を常に意識するよう心がけるべきである。 =head2 ツール =over 4 =item Benchmark.pm Benchmark.pm は、Perl における標準のベンチマークモジュールである。cmpthese, timethese, timeit などを場合によって使いわけるようにする。本稿でも主にこれを用いる。 =it
Kazuho@Cybozu Labs: MySQL の ORDER BY を高速化
« MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話 | メイン | なんとなくリフレクション in C++ » 2008年06月20日 MySQL の ORDER BY を高速化 Pathtraq の拡張にむけて、いろいろ技術的な可能性を調査していると、MySQL の ORDER BY に負荷がかかっていることが分かりました。他にもボトルネックはあるのですが、ここは比較的最適化しやすそうだったので、試しに書いてみました。 mysql51-sort-opt.patch やっていることは、ソートルーチンのベタな最適化です。ORDER BY 句によって悪名高き filesort が実行される場合に、最大30%〜50%ほど高速に動作するようになりました。ただ、自分が書く類いのクエリだと、本質的には top n sort を実装すべきなので、どうしたものかと思っていま
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Second Garage - 東大情報基盤センターの最適化マニュアルが秀逸な件
