sgykfjsm.github.com

MyNA(日本MySQLユーザ会)会 2013年3月に参加した

勉強会中にとったメモが消えたので、各セッションのトピックのみを記載する。

チューニンガソン5の復習 MySQL 5.6 新機能編

スライド

チューニンガソンそのものについては割愛。ここではチューニングについて、どのような視点で取り組むかについてを取り上げる。

  • SQL実行計画を見て、どのようにレコードアクセスされているかの候補を絞り、各パターンに応じたインデックスを貼ってパフォーマンスを計測する。(スライドはこの辺)
  • パフォーマンスが改善しない場合はEXPLAINをとって、貼り付けたインデックスが使われているかどうかを調べる。
  • Optimizer Traceを使う。(スライドはこの辺)
    • SQLオプティマイザの内部動作を調べるMySQL5.6の新機能。
    • マニュアルが無いので、出力内容とソースコードを見比べながら調べる必要がある。
  • Optimizer Traceでの解析により、レコード数の見積もりコストの精度が甘いことが判明
    • パラメータでは変更できないので、MySQL本体を改造。
  • MySQLではこちらの指定したインデックスをどうしても使うことができない場合がある。(スライドはこの辺)
    • STRAIGHT_JOINやFORCE INDEXなどのヒント句をクエリに与えてインデックスの使用を強制する。
    • GROUP BY句で集約されるカラムをインデックスの先頭に配置するLoose Index Scanと呼ばれるテクニックを使うことで、集約の際のソート処理を省略することができる。
    • この効果はEXPLAINでは確認できないので、Optimizer Traceで確認すること。
    • ORDER BY句の処理でディスクソートが発生しないように、sort_buffer_sizeを増やす(MySQL5.6から減らされているので注意)。
  • GROUP BY句にファンクションが使われている場合には、ファンクションをFROM句のサブクエリに囲い込んで中間テーブルを作成するマテリアライゼーションが有効な場合がある(が、バッドノウハウなので非推奨)。(スライドはこの辺)
    • マテリアライゼーションはMEMORYストレージエンジンが用いられるが、メモリからあふれる(tmp_table_sizeを超える)とMyISAMに切り替わるため、tmp_table_sizeの値を増やす必要がある。また、同時にmax_heap_table_sizeも増やしておく(tmp_table_size < max_heap_table_sizeでなければならないため)。
  • 大量のレコードを処理する分析系のクエリではテーブルの非正規化をしたほうが効果的な場合がある。

まとめ

  • MySQLのチューニングは如何に前提条件を覆せるか。不要な処理はなるべく省略できるようにすることが大事。
  • ソースコードを読み解く必要はあるものの、Optimizer Traceは役に立つ。
  • MySQLのオプティマイザはあまり賢くないので、O/Rマッパを使う場合はヒント句を差し込んだりクエリの書き換えが可能となる手段を残しておく必要がある。 

所感

非常に実践的な内容で臨場感のセッションだった。
SQLのチューニングはパラメータいじったり、EXPLAINみながらぐぬぬとなるようなことばかりだったが、紹介されたOptimizer Traceはなかなか便利そうだった。また、クエリをどのように見ていけば良いかという点も大変参考になった。

意外と話題に上がらない、mysqld以外の5.6新機能

MySQLの周辺ツールに関する話題。この辺は説明がどうこうというよりかは自分で触ったほうが早そう。

MySQL 5.6 新機能(熱)

いつもブログを拝見していた奥野さんを生で見れて、テンションが上がったが、ドライバとプロジェクタの相性が悪かったらしく、セッションやデモが不完全燃焼だった。残念。
いずれは奥野さんのブログやYoutube上でのデモが上がるらしいので、今のところは以下を見て慰めとしよう。
MySQL sandboxは面白そうだと思いました(コナミ感)