こんにちは、@hrysd です。
EC事業部で、事業部のパートナーをメインとしこれから半年ほどをかけて @yoku0825 さんにMySQL講座を開催していただくことになりました！
この記事ではそこに至る経緯、第一回目の様子を簡単にお伝えしたいと思います。
講座開催の目的
開催のきっかけ、目的を社内の文章から抜粋して紹介します。
カラーミーショップを中心として、GMOメディアの@yoku0825さんにMySQLコンサルティングの取り組みをはじめて半年がたちました。先日、この半年のふりかえりを行い、次のステップとして、(EC事業部)エンジニアのSQL(MySQL)力の底上げに時間を使いたいという提案をしました。
半年やってみてわかってきたことは、MySQLサーバのパフォーマンス改善にはクエリの改善というのが大きな影響をあたえることができるが、その改善自体は単純なインデックスの追加で解決できるものばかりではなく、実行しているSQLの根本的な変更や分割が必要なものが多いということです。 そのためには、exaplain や、スロークエリログ、この半年で活用してきたスロークエリログを分析する anemometer の見方といった分析の仕方から、MySQLのオプティマイザやインデックスの仕組みなどを理解し、改善の道筋を論理的にたてて検証し、場合によっては機能の変更の提案などを行えるようにならなければなりません。
そこで、上であげたような知識の底上げをするために、EC事業部エンジニア(原則全員としたい)が隔週で1H~2H程度参加する勉強会を、@yoku0825さんのコンサルの一環として開催することにします！
講座の様子
第一回は、
上記のスライドをベースに講義していただきました。 講座の中でも個人的に気になった点・質問をピックアップして紹介したいと思います。
バッファプールについて
バッファプールは全てのクエリが通る場所で、ここにキャッシュがある・なしでパフォーマンスに影響が発生します。 そのため余裕を持ったサイジングが望ましいとスライドでも言及されています。 実際にパフォーマンスに影響が出た事例として、
- バッチ・集計クエリ等の巨大なデータがキャッシュにのり、ユーザに必要なキャッシュがページアウト
- ラウンドロビンで参照を振り分けていたため発生した、キャッシュへのミスヒット
が紹介されていました。
パフォーマンスを意識する時にバッファプールも同様に意識していきたいですね。
「プライマリキーとして UUID を使うのどうなの？」
単純に比較するとストレージを圧迫することもあるので AUTO_INCREMENT なものを使うことが多いです。
例えばプライマリキーの無いテーブルに対して AUTO_INCREMENT なカラムを追加するとテーブルロックがかかるため、後からカラムを追加する状況では UUID をプライマリキーとする利点があります。
「インデックスを追加しすぎると INSERT、UPDATE といったものが遅くなる？」
インデックスに関してはいつコストをかけるか、と考えると良いです。
一般的なWebアプリケーションではデータ取得の回数の方が多いのため、データ追加時にインデックス作成のコストを払い、取得時はそのインデックスを使い返すことでコストを回収するという考え方です。さらに、インデックスは削除するほうが簡単なため基本つけすぎるくらいの気持ちで良いでしょう。
「テーブル圧縮しないほうがいい？」
テーブル圧縮はメモリを犠牲にディスクを守るという戦略であり、一度圧縮すると元に戻せないため無圧縮でスタートするのがオススメです。
圧縮した場合、圧縮前後のデータがキャッシュにのるためバッファプールが荒れる要因にもなります。
最後に
普段なんとなくでやっていたことだったり、仕組みを調べ直すいいきっかけになりました。
次回も楽しみです！