Mysqlデッドロックの問題

最近mysqlジッタの問題に遭遇しましたが、ライブラリを書くloadもioも実は高くありませんが、突然のアクティブリンクの急増があり、調べてみるとループのデッドロックが発生しているので、以前はこの知識をあまり知らなかったので、ちょっと見て、こちらでまとめてみました.
INNODBはMVCCを通じてトランザクションを実現したが、同時環境では次のような問題がある1、ダーティリード:トランザクションAはトランザクションBが更新したデータを読み出し、Bロールバック操作を行うと、Aが読み取ったデータはダーティデータである.2、繰り返し不可:取引Aは同じデータを複数回読み取って、取引Bは取引Aが複数回読み取った過程で、データを更新して提出して、取引Aが複数回同じデータを読み取った時、結果が一致しない.3、幻読:取引Aは条件によって大量にデータを読み取ったり修正したりして、取引BはAが修正を読み取っている間に、新しい条件に合ったデータを挿入して、取引Aが読み取ったり修正したりした後に1本のデータを少なく読んだり変更したりすることを発見した.
INNODBの異なるトランザクション独立性レベルでは、ロックメカニズムが異なり、一部の問題を解決するためにトランザクション独立性メソッドがクエリされます.

mysql> show variables like '%isolation%';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| tx_isolation  | READ-COMMITTED  |
+---------------+-----------------+

独立性レベル
汚読
繰り返し不可
まぼろし読み
READ-UNCOMMITTED
yes
yes
yes
READ-COMMITTED
no
yes
yes
REPEATABLE-READ
no
no
yes
SERIALIZABLE
no
no
no
私の時計はREAD-COMMITTEDです.つまり汚い読みは起こりませんが、繰り返し読みや幻読みができない場合があります.
基本的なロックには、排他ロック(Exclusive Locks、すなわちXロック)と共有ロック(Share Locks、すなわちSロック)の2種類があります.データ・オブジェクトに排他ロックが付加されると、他のトランザクションは読み取りおよび変更できません.共有ロックが追加されたデータ・オブジェクトは、他のトランザクションによって読み込まれますが、変更できません.
XロックとSロックが同時に発生すると、ある行でデッドロックが発生します.具体的には、トランザクションAはレコードをクエリーし、そのレコードを変更します.このとき、トランザクションBがこのレコードを修正すると、ユーザAのトランザクション内のロックの性質がクエリの共有ロックによって排他ロックに上昇しようとするが、ユーザBの排他ロックは、Aに共有ロックが存在するため、Aが共有ロックを解放するのを待たなければならないが、AがBの排他ロックによって上昇できない排他ロックは、共有ロックを解放することができず、デッドロックが発生する.sql自体はロックを解除しようとしますが、具体的なオーバーヘッドが発生し、コード層からこのような状況を回避する必要があります.
私の場合、複数の非同期タスクが同じデータを操作しようとし、デッドロックを起こしました.