MySQLでINSERTのデッドロックに嵌る人を1人でも減らすために - ichirin2501's diary

この記事ははてなデベロッパーアドベントカレンダー2015の12月24日の記事です。 昨日は id:stefafafan さんのエンジニアと英語でした。 こんにちは、こんばんは。 クリスマス・イヴですね、皆さんはどのような一日を過ごされる(た)のでしょうか。 僕は一人です。 改めまして、先日初めての合コンを経験/失敗して二度と行かないと誓った はてなの id:ichirin2501 です。今回は小ネタとしてMySQL(InnoDB)のBULK INSERTにおけるデッドロックの話をしようと思います。ただ、外部キー制約が絡むと複雑になるので今回は触れません。それについてはこちらを参照ください。 あ、タイトルはオマージュです*1。 Topic 検証環境 INSERTのデッドロック 避けられないケース もしくはロックする リトライ処理に注意 初期データ Duplicateの場合 Deadlockの

[shgam]

InnodDBのロック周り難しい

[nobuoka]

これを見て InnoDB のロックのことを調べたりしてる。

[tanishiking24]

"InnoDBは全ての行が生成出来てから全部のロックを獲得するのではなく、生成しながらロックを獲得します。"

[escape_artist]

ふむむ

[lesamoureuses]

へーそうなんだ “InnoDBは全ての行が生成出来てから全部のロックを獲得するのではなく、生成しながらロックを獲得します”

[tmatsuu]

情報処理試験のトランザクションの問題にもでてくるロックの順番を守りましょうと同じやね。それができないなら外部ロックなりテーブルロックだ

[habarhaba]

デッドロックは奥深いですね。トランザクションは万能じゃない…？

[t_f_m]

a...z と z...a のケースはソートで解決って書かれてるけど、ソート済みデータでも a...z と m...z みたいなのが並列で実行されたらやっぱりロックしそうだけど / あー、後者が先に抜けるから大丈夫なのか。自己解決

[yoshikidz]

ネクストキーロックの話なのかトランザクションロックの話なのか。ロックかけないならINSERT IGNOREとON DUPLICATE KEY UPDATEで処理できない場合はロジックかテーブル設計がイケてない気が。

[gikazigo]

やはり金の力で殴るしかない（解決するとは言っていない: MySQLでINSERTのデッドロックに嵌る人を1人でも減らすために - ichirin2501's diary

[tdtsh]

サイクルデッドロックの話

[UDONCHAN]

大変だ

[kazuhooku]

コマンドラインからのバルク処理なら外部ロック取ればいいけど、ウェブアプリの管理画面とかだとこの手の最適化が必要？ / 「INSERT失敗したら重複キーに決まってる」というコードはダメ。必ずエラー値確認しないと

[ya--mada]

ロクスタ

[nakag0711]

insertだけでも分離レベルをread committedに落とすのは…結局行ロックされてるからダメかな。いっそのこと豪快にテーブルロックを取得するのではダメだろうか

[masatomo-m]

これ、BEGIN TRANSACTIONしてトランザクションブロックで囲んでもデッドロックする？まともなDAO挟めば気にしなくて良い気もしたんだけど（もちろんパフォーマンス必要なものは速度とトレードオフですが

[non_117]

これ踏んだ

[dekokun]

BULK INSERTはソート。

[halfrack]

"BULK INSERTはソートしよう" まじで…

[norisu0313]

MySQLでINSERTのデッドロックに嵌る人を1人でも減らすために

[wtatsuru]

これ難しかった