オトコのソートテクニック2008
今日は仕事納めだったので、一年の締めくくりとしてMySQLにおけるソートの話でもしようと思う。 インデックスを利用しないクエリで最もよく見かけるもののひとつは、ORDER BYを用いたソート処理だろう。もし、ソート処理においてインデックスを用いることが出来れば、MySQLは結果を抽出してから結果行をソートするのではなく、インデックス順に行を取り出せば良いので高速にソート処理することが可能になる。特に、LIMIT句やWHERE句を用いて行の絞り込みを行う場合は効果が絶大である。しかし、ひとたびインデックスを利用できない状況に直面すると、たちまちテーブルスキャンが発生して性能が劣化してしまう。 例えば、100万行のレコードを格納したt1というテーブルがあるとする。そのテーブルに対して以下のようなクエリを実行した場合を考えよう。 mysql> SELECT col1, col2 ... colx
1日かかったクエリを1秒で――改善の理由はコンサルにあり
データベースの処理は、しばしばシステム全体の性能を大きく左右する。システムのパフォーマンスが悪ければハードウェアリソースの不足を招き、余計な投資が必要になる。逆に適切なチューニングを施せば、ITコストを抑えられるはずだ。MySQLのエキスパートである、サン・マイクロシステムズのエンジニアに、そのポイントを聞いた。 ビジネス環境が激変する昨今、ITへの効率的な投資を模索する動きが続いている。そんな状況の中、オープンソースに注目する企業も少なくないのではないだろうか。だが、ただ価格が安いからという理由だけで導入してもメリットを得られない。的確なメンテナンスを行わなければ、ハードウェアリソースの不足によりさらに投資が必要になることもある。 1日以上かかっていたクエリ処理を1秒に短縮 システムの性能を大きく改善する可能性があるのが、データベースのパフォーマンスチューニングだ。パフォーマンスチューニ
Best Practices for Speeding Up Your Web Site - Yahoo Developer Network
Best Practices for Speeding Up Your Web Site The Exceptional Performance team has identified a number of best practices for making web pages fast. The list includes 35 best practices divided into 7 categories. Minimize HTTP Requests tag: content 80% of the end-user response time is spent on the front-end. Most of this time is tied up in downloading all the components in the page: images, styleshee
ウノウラボ Unoh Labs: PHP最適化tipsまとめサイト
こんにちは。親知らずを抜いて離乳食三昧のyukiです。GWの暴飲暴食から脱し、ダイエットするには好都合ですね。すいません。負け惜しみです。 さて、今回は「PHPのちょっとしたコツ」の続きネタで、PHP最適化Tipsまとめサイトの紹介です。 これらは既に有名なサイトで紹介されていたり、常識の範囲かもしれませんが、ひとつでも有用に感じていただければ幸いです。 そして英語が極端に苦手なため、意訳突っ込み等あれば宜しくお願い致します。 PHPの最適化 12 PHP Optimization tips (元ネタはこちらでしょうか？ http://www.ilia.ws/files/zend_performance.pdf) staticが使えるなら、staticを使う。速度は4倍になる。 __get, __set, __autoload は避ける。 require_once() はコストがかか
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.res-system.com/weblog/item/550