MySQL勉強会〜ロックについて(基礎編)〜を開催しました!

f:id:fkmy:20200713122808j:plain

はじめまして、ソフトウェアエンジニアの福間( fkmy )です。早いもので入社してから10ヶ月が経ちました。 普段は新規サービスのAPIをRailsで書いてます。リモートワークも数ヶ月目に入り自宅の開発環境が快適になってきました。先月はモニターアームを買いましたが出費がかさみますね。

さて、この記事は7/6(月)にANDPADのデータベースの技術顧問をして頂いてる三谷(@mita2)さんに発表してもらった開発部向けのMySQL勉強会(ロック基礎編)のレポートとなります。 今回は在宅勤務期間中のためオンライン開催となり、当日は16名が参加していました。


開催背景

社内からデータベースのロックについて勉強会をしたい!!というメンバーからの声があり開催となりました。

※ブログで取り上げられてはいないのですが「MySQLのチューニング」についても1ヶ月前に実施しています。


内容

当日の資料はこちらになります。


個人的に気になった内容や質問をいかで5つピックアップして以下で紹介したいと思います。

1. なぜロックが必要か

f:id:fkmy:20200707161846p:plain

  • パフォーマンスを出すためにトランザクションを並列で実行するとレコード競合が発生してしまうため、競合を防ぐためにロックが必要となります。
  • 余談ですが実装依存で発生するロックとは別に内部で実行されるシステム的なロックはラッチ(Latch)と言うそうです。


2. InnoDBのロック

f:id:fkmy:20200707162046p:plain 「条件に合致した行」に対するロックではなく「インデックスに対するロック」が掛かること、ロックの範囲は実行計画に依存することを事例を踏まえて紹介していただきました。また大量DELETE時はロックが発生するケースが多いため、対象レコードの主キーをSELECTして削除するのがお作法だそうです。


3. 外部キーのロック

f:id:fkmy:20200707163013p:plain 外部キーを持つレコードを追加/更新する場合、親テーブルにも共有ロックが掛かります。 親テーブルにロックが掛かる理由ですが外部キー制約違反を防ぐためとなります。


4. ロックに関するエラーの調査方法

f:id:fkmy:20200707163447p:plain 競合しているトランザクションの調査方法、デッドロックの対処方法について具体例を元にログのみるべきポイント、推測方法などを紹介していただきました。


5. 「大量データのインポート処理を All or Nothingでしたい場合、ロックの問題は発生するのか?」

外部キーを持つ子テーブルの場合、親テーブルに対して共有ロックが発生する可能性があります。 All or Nothingにはなりませんが、子テーブルへのインポート処理のトランザクションを細かくする方法も考えられます。


さいごに

普段あまりロックのことまで気にして開発することがなく、InnoDBや外部キーのロックについても知らない状態だったので勉強になりました。ロックのエラー調査については経験による推測や訓練が必要になるとのことなので私もMySQLの気持ちを推測できるように経験を積んでいきたいと思います。

データベース勉強会は月1くらいの頻度で開催されているので次回の開催も楽しみです!


ANDPADではエンジニアを募集しています

今回のMySQL勉強会に限らず定期的に勉強会を開催してみんなで成長しようとしていますので、もしご興味持っていただけたら以下の採用サイトから詳しい職場環境などもご覧になってみてください!

engineer.andpad.co.jp