Optimizing Subqueries, Derived Tables, View References, and Common Table Expressions Optimizing IN and EXISTS Subquery Predicates with Semijoin and Antijoin Transformations
週に一度か二度、Bacteriaが管理するサイトは大規模なプロモーションをすることがある。 140万通ものメール広告でもってやるわけだけど、そのレスポンスが強烈に重い。 サーバが悲鳴を上げているのがわかる。 ちょっと重すぎるよこれどうなってんのってことで、MySQLのslow_queryで分析をはじめることにした。 すると一番最初に引っかかったのが下記の事例だった。 MySQLにクエリを投げる場合、Explainして最も見たくないのがUsing file sortの文字だ。 file sortは負荷がかかると、Using Temporaryまで出てき始める。 こうなるともうお手上げで、クエリは結果を表示するためにディスクアクセスを繰り返し、速度は低下の一途をたどることになる。 file sortが発生するときは、たいてい決まっているがorder byを使うときだろう。 そりゃそ
komagataです。 Webアプリケーションのパフォーマンスの大半はデータベース、特にインデックスの使われ方にかかっている気がします。 仕事でもMySQLをよく使いますが、MySQLでは1テーブルに付き1インデックスしか使われません。PostgreSQLなどと比べてそのことが気になってMySQLでのパフォーマンスチューニングに全く自信が持てませんでした。 オライリーの実践ハイパフォーマンスMySQLには下記のように書かれています。 実際、UNIONを除き、MySQLでは、1つのクエリを実行するとき、1つのテーブルに付き1つのインデックスしか使用できない。この事実は、繰り返し述べるに値するほど重要である。「MySQLでは、1つのクエリを実行するとき、1つのテーブルにつき1つのインデックスしか使用できないのである。」 また、その制約を考えたクエリの書き方として下記の様に書いてあります。 my
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く