なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
FlickrがPHP4からPHP5に移行 – 秋元
Flickr上で先月出された「このグラフの変化は何?」というクイズ 答えは、「PHP5に移行したFlickr.comのサーバのCPU利用率」ということでした。サーバのスクリプトエンジンをPHP5に切り替えた際に、上記のようなＣＰＵ利用率の削減が見られたということです。 このクイズを出したのは、Yahoo/Flickrでキャパシティ・プランニングを担当するジョン・アルスポーさん。先週のWeb2.0 ExpoでFlickrのサーバマシン入れ替えとパフォーマンス改善について話されています。 Web2.0 Expoのスライドで話されているのは、以下のような内容です。 Ｆｌｉｃｋｒのストレージ構成やデータ量 PHP5移行でCPU利用率が15%減ったこと ImageMagickからGraphicsMagickに変更して高速化 ＯｐｅｎＭＰでサムネイル作成を並列化 サーバマシンを良いスペックのものに置き
sysctlによるカーネルのチューニング - SourceForge.JP Magazine
Linuxカーネルは柔軟性が高く、sysctlコマンドを利用すれば、カーネルパラメータを動的に変更してその場で動作を変えることさえ可能だ。sysctlのインタフェースでは、LinuxまたはBSDの何百というカーネルパラメータを参照したり変更したりできる。変更はただちに反映されるが、リブート後まで変更を保留する手段もある。うまくsysctlを使えば、カーネルを再コンパイル（翻訳記事）しなくてもマシンの最適化が可能であり、しかもその効果をすぐに確認できる。 とりあえずsysctlでどんな変更ができるのかを知るには、「sysctl -a」を実行して扱えるパラメータをすべて表示するといい。そのリストは非常に長いもので、私のマシンでは712もの設定可能な項目が表示される。 $ sysctl -a kernel.panic = 0 kernel.core_uses_pid = 0 kernel.cor
MySQLの最適化
限りなく眠気を誘うPHP Internalsのセッションから逃げる。こっちの 講師はMySQL.comの人。講演慣れしていて、ずっとまともでプロフェッショナルな 感じ。午前中を逃したのが惜しいが、詳しいプレゼン資料は後日公開される らしい。 DELETEのコストはかなり高い 読みだしがすごく多い場合は無効化を示すフィールドを作りUPDATEすべき、 index更新のコストが馬鹿にならないSHOW STATUSの表示結果の解析方法 起動ごとに初期化、全データベースに共通rnd と rnd_next の割合Key_reads : Key_read_requests 、ディスクから読まれた回数：総回数 この割合が1:100より悪くなったら要注意Key_write_requests:Key_writes 総書き込み要求回数：ディスクに書き込ま れた回数 キャッシュの効果などMax_used_con
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
InnoDB のパフォーマンスチューニング - MySQLカンファレンス2007 - akiyan.com 管理人メモ
http://www.mysql-ucj2007.jp/details/j25.html 木下 靖文 氏 NTTコムウェア株式会社 プロジェクト管理統括部技術SE部門 DB技術グループ （「InnoDB」は「いんのでーびー」と言うらしい...今まで「いのでーびー」と言ってました） InnoDBをなぜ使うか トランザクション コミット、ロールバック、セーブポイント 外部キー 行レベルロック オンラインバックアップ クラッシュリカバリ クラッシュリカバリ MyISAMはデータ量の増大とともに時間がかかる InnoDBはデータ量の増大との相関がない InnoDBチューニングの王道的アプローチ クエリを改善して全体的に処理効率を上げる データサイズをできるだけ小さく メモリをできるだけ多く積む コミット性能（同期書き込み） innodb_flush_log_at_trx_commit=1,0,2
MySQLの高速化 Tips - memo.xight.org
Summary my.cnf [client] # セキュリティ面から変更すべき port = 3306 [mysqld] # インデックスをバッファに保存する際のメモリサイズ # MyISAMならOSキャッシュも使用するため，全メモリの30-40%を当てると良い． key_buffer = 256M # InnoDBはOSキャッシュを使用しないため，全メモリの70-80%を当てると良い． innodb_buffer_pool_size =512M # データのキャッシュサイズ．I/Oを減らす． # 数百のテーブルであれば，1024が良いらしい． table_cache = 256 # スレッドの作成，削除は負荷が大きい． # Threads_Createdの動きを見ながら変更． thread_cache = 16 # あまり効果は無いらしい． #innodb_additional_poo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
株式会社スタイルズ
Linuxチューニング ---目次：ITpro
IBM Developer