どのような状況で mysql がデッドロックしてしまうのでしょうか?

Deadlock in mysql: 実行中にリソースの奪い合いにより 2 つ以上のプロセスが互いに待ち状態になる現象を指します。外部からの力がなければ先に進むことができません。このとき、システムがデッドロック状態にある、またはシステムにデッドロックがあると言います。常に相互に待機しているこれらのプロセスは、デッドロック プロセスと呼ばれます。テーブル レベルのロックではデッドロックが発生しないため、デッドロックの解決は主に最も一般的に使用される InnoDB に重点が置かれます。

推奨コース: MySQL チュートリアル 。

デッドロックの鍵は、2 つ (またはそれ以上) のセッションがロックされる順序が矛盾していることです。

したがって、デッドロック問題を解決するための対応する鍵は、さまざまなセッションを順番にロックすることです。

ケース

要件: 資金を投資するいくつかのトランシェに分割され、借り手にランダムに配布されます。

最初のビジネス プロセスのアイデアは次のとおりです。

投資家が投資した後、金額がランダムにいくつかの部分に分割され、その中からいくつかがランダムに選択されます。次に、select for update を使用して借入者テーブルの残高を更新します。

たとえば、2人のユーザーが同時に投資した場合、ユーザーAの金額がランダムに2回に分けられ、借り手1、2に分配されます。ユーザー B の金額をランダムに 2 つに分け、借り手 2 と 1

に割り当てますが、ロックの順序が異なるため、当然すぐにデッドロックが発生します。

この問題の改善は非常に簡単で、割り当てられたすべての借り手を一度にロックするだけです。

Select * from xxx where id in (xx,xx,xx) for update

mysql のリスト値は自動的に小さいものから大きいものへと並べ替えられます。ロックも、小さいものから大きいものまでの一連のロックです

 例如（以下会话id为主键）：
 
Session1:
 
mysql> select * from t3 where id in (8,9) for update;
+----+--------+------+---------------------+
| id | course | name | ctime               |
+----+--------+------+---------------------+
|  8 | WA     | f    | 2016-03-02 11:36:30 |
|  9 | JX     | f    | 2016-03-01 11:36:30 |
+----+--------+------+---------------------+
rows in set (0.04 sec)
 
 
Session2:
select * from t3 where id in (10,8,5) for update;
锁等待中……
 
其实这个时候id=10这条记录没有被锁住的，但id=5的记录已经被锁住了，锁的等待在id=8的这里
不信请看
 
Session3:
mysql> select * from t3 where id=5 for update;
锁等待中
 
 
Session4:
mysql> select * from t3 where id=10 for update;
+----+--------+------+---------------------+
| id | course | name | ctime               |
+----+--------+------+---------------------+
| 10 | JB     | g    | 2016-03-10 11:45:05 |
+----+--------+------+---------------------+
row in set (0.00 sec)
 
 
在其它session中id=5是加不了锁的，但是id=10是可以加上锁的。

以上がどのような状況で mysql がデッドロックしてしまうのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。