MySQLで発生し得る思わぬデッドロックと対応方法

はじめに この記事は実際の業務で発生した MySQL のデッドロックとそのいくつかの回避方法や対応方法を（テーマは変えて）手元で実行できるコードを用いて解説する記事です。具体的には「トランザクション張っておけば大丈夫」と思ってませんか？ バグの温床になる、よくある実装パターンの記事で紹介されている「1on1 チャットサービス」で紹介されているデッドロックとデータベースレイヤでは同じ状況だったのですが、記事で紹介されている方法とは別の方法でデッドロックを回避する必要があったため、同じ状況に遭遇した人の助けになればという思いで記事を書きました。また、こちらの記事が無ければ私自身も現象を理解するのにもっと苦労したと思うので、この場を借りてお礼申し上げます！ 出金サービス履歴登録サービスを例に考える コードと説明が https://github.com/shuntagami/withdrawal_

[sin20xx]

MySQLで決済とかセンシティブな仕組み実装する時は基本MySQLのロックに頼ってはダメが鉄則かな。僕は大抵Redisとかその手の仕組みで個々にロック状態、取引状況を管理する状態管理を作った上で整合性を保つ方法にしてる。

[taruhachi]

頻度の問題だけど、できればデッドロック発生したらエラーを返しておけばとりあえず大丈夫という方向に倒して設計したい。リカバリのための複雑な仕様を盛り込みすぎると別の問題を発生させて死ぬ事がある。

[rgfx]

via: https://twitter.com/mpyw/status/1543996327755153408

[tmatsuu]

ん？なんか違和感あるな。SELECT … FOR UPDATEでUPDATEする対象レコードのロックを取ってるけど、そのあとにやってるのはINSERTだから正しくロックが取れてないというだけちゃうかな。

[nabinno]

PostgreSQLはこの辺どうなんだろ。

[turanukimaru]

ロックかけずに insert してその後 select しなおして金額オーバーしたら取り消し処理してる。update はしない。これで問題があるなら誰か教えて欲しい（他力本願。問題って自分ではわからないものなのよね…

[buzztaiki]

mysqlこの辺めんどい。

[s_rsak]

MySQLのテーブルロックって、使うテーブルを全部ロックしないといけないから、使いづらかった記憶がある。

[matsubobo]

自分の設計を見直してみたけど問題無さそうだった。 https://matsu.teraren.com/blog/2022/02/03/point-system-design-rdb/

[tettekete37564]

DB 外での排他制御導入はね・・・RDBMS の導入が今ほど簡単で安くなかった頃はファイルベースでの排他制御がキモだったけど。

[codehex]

排他制御難しいよねー

[PrivateIntMain]

わかりやすい。ユーザーでロックする方針にすると他機能とかちあうのが嫌なんで、ユーザー残高テーブルを別で作りたい派。(かちあうのを許容するなら別にいらない)

[bopperjp]

図が死ぬほど見やすい。こう書けばいいのか。。

[Keisuke69]

なんか似たようなことにハマったことが遥か昔にあった気がする

[versatile]

そうね。レコードない時ね。ロック用レコード登場おおおなんだよねぇ。どうにかならんもんか

[nekochiyo]

勉強になった

[t_f_m]

あとで