MySQLロックについて〜基礎編〜を開催しました！

こんにちは！エンジニアの福間（fkm_y）です。先日、弊社でデータベースの技術顧問をして頂いてる三谷（mita2）さんに開発部向けのMySQLロックのデータベース勉強会を実施したのでそのレポートをお伝えします。

開催背景

弊社では三谷さんによるデータベース勉強会を定期的に開催しています。以前にもロックに関するMySQL勉強会を開催していたのですが、1年半経過しており参加していない開発メンバーのほうが多くなっていたことやプロダクトの成長によりデッドロックなどのロックに起因する問題が目立ち始めていたことから増強版のMySQLロックのデータベース勉強会を開催することになりました。

概要

データベースのロックについて
ロックタイムアウトについて
デッドロックについて
まとめ

データベースのロックについて

なぜデータベースにロック機構があるのかから知ることが重要です。性能と安全性を両立するためにあるということから丁寧に解説していただきました。

レコードロックというと「条件に合致した行」のみがロックされると勘違いされがちですが、「スキャンしたインデックス」に対してロックすることを覚えておくことが重要です。そのためロック範囲は実行計画に依存するためクエリチューニングを適切に行うことも重要です。

ロックタイムアウトについて

ロックタイムアウトは、先行するトランザクションが保持しているロックの解放の待ち時間がinnodb_lock_wait_timeoutパラメータの値を超え、タイムアウトすることによって発生するエラーです。デッドロックは即時にエラーとなりますがタイムアウトは待ち時間を用してからエラーとなるため、ユーザー体験はデッドロックより損ねてしまいます。

ロックタイムアウトの原因はinnodb_lock_wait_timeoutを超えるトランザクションが存在することであるため、基本的にはパフォーマンス問題になります。そのためどこでパフォーマンスが遅くなっているか調査して対応する必要があります。

ANDPADでは Bugsnag、Datadog APM、CloudWatch Logs を導入しており、それらを利用したロックタイムアウトの調査方法について解説していただきました。

ロック待ちになったトランザクションを調べるため、Bugsnagでエラーの発生時間、エラーが発生したソースコード、テーブルを確認した後、Datadog で実際のクエリを確認します。
ロックしていたトランザクションを調べるため、Datadog APM を利用してエラー発生時間前後の処理を確認します。その後、生クエリを確認するため CloudWatch Logs を確認します。

※一部非公開ですが、後述のスライドで詳細が説明されています。