デッドロックは、私は誰もが、平野話すが、両方のすべての側面を食べるために方法はありません、その結果、ボウルがお互いを見つめ、彼のボウルが食べているに精通していると信じています。
例えば、商人は非常に複雑なデータベース操作のシリーズを完了します、ものを買って、私たちは、アカウントの量A -50は、その後、事業の量は50で、二つの操作に簡略化することができます。アカウントの量を増加させると同時に、中小企業も還付Aを見直し、2つのちょうどこの最後の操作を完了したので、100の事業の量、100。だから、我々は修正行ロックアカウント作られた一つの操作の前に、アカウントが50 Aによって削減されますが、トランザクションは、商人のアカウントに50を増大させる必要が完了していません。トランザクションが完了していない場合は、ビジネスを作った行ロックの背後で動作し、商人のアカウントマイナス100と、Aさんを取得し、その後、アカウント100の量を増やす行ロックを待つことも必要です。
このように、ユーザーの撮影した行ロックへ前のトランザクションは、業務トランザクションは、ユーザのロックを待って、ロックを取得後ろにビジネスをロックするのを待って、二人は、トランザクションは、デッドロックの形成を完了することができない、満たすことができません。MySQLは、デッドロックが発生したときに、どのようにそれを行うだろうか？MySQLはinnodb_lock_wait_timeout、このような構成です。双方はデッドロック場合つまり、後に多くのこの時間よりも、双方は、再び、それが競合しない場合には、この時間を手放します。この時間が長すぎる場合は、我々は2秒の実装を実行します。この文を持っていた、彼らはとして傷害に接着することができるように、この時間は、短すぎる設定されて置けば、ユーザーは、それを数十秒待ってから、再試行を任せることはできません、タイムアウトは1秒で、最終的なトランザクションがロールバックされた結果セットは、白乾燥に等しいです。
MySQLはまた別の関数は、それは、他のスレッドを横断するために行くことは、デッドロックがあるかどうかを確認します私たちは、時間上の文は、ロックを取得しない実行されるたびに、このスイッチをオンにした場合、デッドロック、innodb_deadlock_detectをチェックすることです提供します。通常の状況下で、私は千のスレッドがある場合は、同時に同じ行を更新、例えば、このスイッチをオンにすることはお勧めしませんが、各トランザクションは、他の999件のスレッドがロックされますので、それが必要であるだけで一つのことをやっています大きなオーバーヘッドが生じる、デッドロックを形成するかどうかを確認するために、互いを横切ります。
だから、どのように我々はこのデッドロックは、それが発生しないようですか？私は、彼らが可能デッドロック状況を回避しようと、それはビジネスの設計時にすべきだと思います。まず第一に、我々は払い戻しのための支払いをすることができない理由など不合理な設計、上記の例を避ける必要があり、ユーザーの量を動作するように設計され、その後、事業運営の量は？我々は、以前の同時SQLを高度に言及していませんトランザクションの効率をより助長業務、背面の声明。デッドロックの可能性を低減しながら、両方を行います。