MySQL Adminが見た Devs の常識、DBAは非常識
- DBA からのマサカリ集
- MySQL 4.0 から 5.6 への移行
- レコードが3000万件あり、パーティショニングしても遅いのでスケールアウトしたい
- スケールアウトのしどき
- buffer pool hitrate も見よう
- 新規のテーブルをつくるときはレビューしているが、何をレビューしているのかケチがついた
- SQL レビューって?
- 文化な話もあるけど
- 「今」「想定どおりのインデックスで」「想定どおりの結果がかえってくる」のは当たり前
- 今よりレコード件数が増えても「想定通りのレスポンスで」結果が帰ってくることも勘案してください
- EXPLAINの select_type が dependent subquery、type が all、Extraがusing temporary table や using file sort の場合はだいたい件数が伸びてくると重くなってきます。
- 行けてないクエリは件数が多くなってくるほど重くなる場合が多い
- SQL レビューって?
- 最近親テーブルと子テーブルの間でデータ不整合が
- このクエリなんとかならないの
- 相関サブクエリー使ってる
- サブクエリーの内側の WHERE 句で外側クエリーのテーブルのカラム参照してるやつ
- 相関サブクエリーは外側クエリーからフェッチした行数だけサブクエリーを実行するので外側クエリーのテーブルが大きくなればなるほど一気に重くなる
- CPU 使用率を跳ね上げることが多い。というか CPU しようりつが跳ね上がったら大量アクセス
- インデックスが足りない
- パラメータがイケけてない
- イケてないクエリが特定できない場合
- そのままではスロークエリログに乗らないクエリー
- set global long_query_time
- log_queryies_not_using_indexes = 1
- pt-query-digest, mysqldumpslow
- pager egrep -v "sleep|handlersocket|binlog dump" からの show full process list を連打
- おすすめ
- 5.6 に deprecated に
- まずはEXPLAIN
- Keyで想定しているキーが使われているか、Key Lengthが想定している長さで使われているか
- int, datetime, vachar(32) のキーなのに key length が 4 だと int しか使われていない
- Using file sort はおそい
- Keyで想定しているキーが使われているか、Key Lengthが想定している長さで使われているか
- set profiling = 1; からクエリー実行、show profile;
- 5.6 で deprecated に
- そのままではスロークエリログに乗らないクエリー
- 相関サブクエリー使ってる