MySQL 5.7 初心者向けセミナー　～チューニング基礎編、SQLチューニング編～ 20170814

しょー（show） @surumegohan

innodbのキャッシュを確認する処理はオーバヘッドがかかるので注意 #mysql_jp

しょー（show） @surumegohan

スキーマのデザイン。基本的には正規化！正規化しないと後から困ることたくさんある。その上でJOINが多いから非正規化するなどのアプローチにしよう。テーブルを設計するなら冗長性を排除していくのが基本。 #mysql_jp

まみー @mamy1326

スキーマ―のデザインについては「現場で役立つシステム設計の原則」にも書いてある。正規化とかデータ型とか。 #mysql_jp

しょー（show） @surumegohan

データ型はできるだけ小さい型を使った方がいい。INTではなく、tyniintなど必要な範囲にすることで最適化できる。JOINに使う列は同じデータ型に。char型よりはvarchar型を使おう。NOT NULL制約をきちんとつける。 #mysql_jp

しょー（show） @surumegohan

もちろん現場や環境によって調整するパラメータの項目や値は変わります。 #mysql_jp

しょー（show） @surumegohan

質問タイム。 Q.コネクションスレッドのキャッシュはキャッシュすることでどういうオーバヘッドが減らせるか。 A。新規コネクションをはるときに新たに生成する必要がなくなるから効率的。 #mysql_jp

しょー（show） @surumegohan

Q.使いまわさないメリットはメモリがあくくらい？ A.スレッドが新しくたつなら結局メモリを使う。 Q.キャッシュは多めに設定した方がいい？ A.不必要に多めにする必要はない #mysql_jp

しょー（show） @surumegohan

Q.設定を動的に変えれるものか変えれないものもあるが、今回説明しているのは動的か A.パラメータによるので再起動しないと変えられないものも含むのでマニュアルをみてください #mysql_jp

しょー（show） @surumegohan

補足：sort_buffer_sizeはセッション単位で変えられるので、夜間バッチだけソートが多いならその時間帯だけ大きくするという運用もある #mysql_jp

しょー（show） @surumegohan

Q.innodb_io_capacityはAWSでも対応してる？ A.オラクル社にフィードバックがないので判断ができないです。。。 #mysql_jp

まみー @mamy1326

@surumegohan 補足します！RDSはフィードバックないので判断できない。EC2にMySQL立てるなどで、ストレージを選択できる場合は、選択したものに応じて設定すれば良い、と受け取りました！ クラウド上でも、MySQLそのものを使うなら、選択するストレージの性能に合わせてね、ということかな？

しょー（show） @surumegohan

Q.クエリキャッシュが使えなくなると代替手段がある？ A.現状、置き換え機能はないです。 #mysql_jp

まみー @mamy1326

@surumegohan 振り返り用に。 クエリキャッシュは検索結果、1万件あれば1万件、100件なら100件、データが更新（対象のテーブルのどれかが更新）でキャッシュは消える InnoDBのバッファプールはデータとindexそのもの。検索前の生。通常は検索時にDiskを見るが、キャッシュからも返せる

しょー（show） @surumegohan

Q.コネクションプールを使ってる場合、コネクションをはっているけど使っていないスレッドがあるか判断することはできる？ A. show full process？というコマンドでみれる　後で説明します。 #mysql_jp

しょー（show） @surumegohan

Q.クエリキャッシュとInnodbのバッファはどっちが優先される？ A.まずキャッシュするものが違う。クエリキャッシュはSQL結果そのもの。クエリキャッシュに引っかかったらそのまま返すのでSQLは実行されないです。 #mysql_jp

しょー（show） @surumegohan

Q.Innodb_buffer_pool_sizeは80％ってのはO_DIRECTじゃないときとかページサイズを変えた時とかどうなのか？ A.80％というはざっくり「できるだけ多くとりましょう」という意味なので、データとインデックスが全部のるのが理想。 #mysql_jp

まみー @mamy1326

@surumegohan データを全部、もしくはホットデータ（メモリにどうしても載せたい OR 載せるべきデータ）を全部メモリに載せられない場合は、物理メモリの8割を目安に最大限、メモリに載せられるようにしましょうね、という理解です。

しょー（show） @surumegohan

#mysql_jp twitter.com/mamy1326/statu…

lhfukamachi @lhfukamachi

本日はメモとることでいっぱいいっぱい。。。 #mysql_jp

しょー（show） @surumegohan

#mysql_jp twitter.com/mamy1326/statu…

しょー（show） @surumegohan

クエリキャッシュの補足。 利用率が下がった背景、SQLが同じ結果を返すならアプリサーバ側で完結するパターンの方が負荷が低いから。memcachedとかキャッシングの技術も増えている。なのでDB側でキャッシュするよりアプリ側でキャッシュさせる流れになっている #mysql_jp

しょー（show） @surumegohan

SQLチューニングの流れ。 まず、どのSQLをチューニングするか特定しないといけない。特定したら実行計画や稼働統計を確認する。 SQLの内部的な処理についてはSQL文では定めていない。（ヒント句を除く） オプティマイザの実行計画に任されている。 #mysql_jp

しょー（show） @surumegohan

SQLチューニングの代表例。Indexを作成する、削除する。ヒント句を使用する。JOIN順番を変更する。特定のINDEXを使用させる。システム変数を変更するなどなど #mysql_jp

しょー（show） @surumegohan

まず、問題となるSQLをどうやって特定するの？ スロークエリーログをみよう！ 実行時間が指定した時間以上のクエリを出力できる。単位はマイクロ秒まで指定できる。デフォルトでは指定されてないので使うなら設定する。 #mysql_jp

しょー（show） @surumegohan

スロークエリには時間ではなく、INDEXを使ってないクエリを出力させることも可能。 注意点：クエリの実行が完了してから記載させる。 #mysql_jp