MySQL のチューニングについて考えてみた

MySQL のチューニングについて考えてみた tokuhirom

MySQL は遅いか速いかたぶん、速い。たいていの場合は。でもときどき遅い。

遅い原因の見つけ方 Mysql の slow query log をみる表示に時間かかっているページをみつけて、そこのページの SQL を最適化してみたりする

EXPLAIN を制するものは MySQL を制す

EXPLAIN の使い方 EXPLAIN SELECT COUNT(*) FROM foo; id: 1 select_type: SIMPLE table: NULL type: NULL possible_keys : NULL key : NULL key_len: NULL ref: NULL rows: NULL Extra: Select tables optimized away

EXPLAINの見方インデックスがきいてるか、どうか。 possible_keys : NULL key : NULL

JOIN が遅い。 SELECT * FROM a INNER JOIN b (b.a_id = a) … 4 つとか JOIN すると遅い。

Using temporary; テンポラリーテーブルを作る。遅い。ユーザーが見てるページで、これがでてくるクエリを発行したらダメ。

JOINを回避する方法 SELECT * FROM a INNER JOIN b (b.id=a.b_id); を SELECT * FROM a; SELECT * FROM b WHERE id IN (?, ?, ?, ?); に分割する。

How to implement my @rows = Proj::Schema::Foo ->fetch_with_cache_multi(@ids);

get_multi の考え方 Memcached での考え方。複数キーで一気にひっぱってくる。

fetch_with_cache_multi() local $DBIx::Class::ResultSourceHandle::thaw_schema = $c->model_slave; なんかやっとかないといけないらしい。

fetch_with_cache_multi get_multi するとれなかった分は IN でひっぱってくる。 set_multi するまとめて返す。

set_multi? Cache::Memcached::Fast

なぜ multi だと速いのか select loop をまわします。。。

MySQL のチューニングについて考えてみた

Recommended

More Related Content

Viewers also liked (13)

More from Tokuhiro Matsuno (13)

MySQL のチューニングについて考えてみた