MySQLの実際のアプリケーションで発生したロックの問題

最近、プロジェクトで事務間のデッドロック問題が発見されたので、MySQLロックメカニズムを研究し、MVCCなどの周辺知識まで拡張しました.ここで開発中に発生する可能性のある問題を紹介します.具体的な内容は『高性能MySQL』を読むことをお勧めします.
前言:mysqlには2つのロックメカニズムがあります.リードロック(共有ロック)とライトロックです.1つのプロセスがリードロックを取得すれば、すべてのプロセスが読むことができますが、書くことはできません.1つのプロセスがライトロックを取得すれば、このプロセス以外のプロセスは読み書きができません.myisamではデッドロックの問題もトランザクションもサポートされていないため、ここでは主にinnodbのロックメカニズムについて説明します.
1、2つのプロセスは同時にデータベースの同じレコードにアクセスします.1つは読み取り、1つは書き込みです.mysqlではどのように実行されますか.myisamでは、書き込みロック(ロックテーブル)が先に行われ、書き込み操作が後にブロックされ、書き込み操作がロック解除されてから読み取り操作が行われるのですが、なぜかというと、mysqlでは書き込み操作の優先度が読み取り操作よりも高く、書き込み操作の方が読み取り操作よりも遅くなることもあり、innodbでは同時に行われるので、互いに干渉しないのがMVCC(マルチバージョン制御)のおかげです.
2、事務中のデッドロック?

 //SQL1
 start transaction;
 update test set name='wjw' where id=1;
 update test set name='wy' where id=2;
 commit;

//SQL2
 start transaction;
 update test set name='wjw' where id=2;
 update test set name='wy' where id=1;
 commit;

上の2つのトランザクションは、1番目のsqlを実行した場合、2番目のトランザクションは2番目のsqlを実行しますが、1番目のトランザクションでid=1のローがロックされ、1番目のトランザクションcommitが待機します.1番目のトランザクションが2番目のsqlを実行した場合、2番目のトランザクションがid=2のローをロックしていることがわかります.したがって、2番目のトランザクションcommitを待つと、デッドロックが発生します.ここには、トランザクションが全体であり、すべての実行が完了してから終了するという知識があります.これも、sqlを実行した後もローをロックする理由です.
解決策:デッドロックは多くのデータベースに存在し、解決策はデッドロックを避けることです.例えば、上記の例では、2つのトランザクションのsql数順を同じように書くことができます.最初の更新id=1、2番目の更新id=1です.innodbでは、デッドロックが発生したかどうかを自動的に判断します.発生した場合、1つのトランザクションが成功し、もう1つのトランザクションがdeadlockedエラーを報告します.
3、もし二人が同時に文章を編集して衝突したらどうしますか.第1人が編集し終わって提出した時、しかし第2人は知らないで、彼は編集し終わっても提出して、このように第1人の編集の内容をカバーして、これは楽観的なオフラインロックの概念を引き出して、具体的な内容は私の別の文章を見ることができます==>12306切符を奪う問題
PS:表現力が限られていて、何か問題があったら、交流を歓迎します.