データベースの並行性の問題

同時操作は、一連の問題をもたらします

1. 失われた（失われた更新）を更新

   二つ以上のトランザクションが同じ行を選択すると、初期値に基づいて選択された最後の他の企業によってカバーされ、更新、各トランザクションは、他の事項の存在を知らないので、失われたアップデートの問題が発生する可能性が流用更新されますアップデートを行います

2. ダーティリード（ダーティー読み取り）

   トランザクションが矛盾した状態で、このレコードに、データをトランザクションが完了する前に、レコードを変更するために行われ、提出され、この時間は、別のトランザクションでも同じ基準を読んで、制御されない場合は、2番目のトランザクションこれらの「汚い」データを読み、それに応じて更なる処理のために、それが呼び出された依存関係コミットされていないデータ、作成する「ダーティリードを。」

3. 非反復可能読み取り（非反復読み取り）

   特定の時点でのトランザクションは、データの一部を読んで再び前回の読み出しデータを読み出すが、読み出したデータが変更されたこと、または特定のレコードが削除されることがわかりました！！これは、非反復可能読み取りと呼ばれています

   （アイソレーションに準拠していません）

4. マジック読書

   トランザクションは、同じクエリデータが前に見た検索読み込みますが、見つかったの挿入、他のトランザクションをその条件を満たすように、新しいデータクエリを再びなしがあったかのように呼ばれる現象「ファントム読み取り」、

    

   トランザクション分離レベルのMySQLを設定すると、MySQLは自動的に同じラインデータを操作するためにロックします

    

    

   MVCC機構、マルチバージョン同時制御、マルチバージョン並行処理制御機構を使用して反復可能読み取り、MySQLの

   バージョンは更新されません選択動作が、各クエリは、スナップショットのバージョンでスナップショットを行います。その後の変更だけでなく、実際のデータとスナップショットのバージョンの後に矛盾しているが、MySQLのロジックが正確でできるようにするためには、最新のデータが更新された場合、データベースを更新するデータのスナップショット版を読み、読みます。

   この理由のために、ある売られ過ぎの商品、。

    

   https://blog.csdn.net/huaishu/article/details/89924250

   これは、現在のスナップショットが読んで違いを読んで

   スナップショットは、高いパフォーマンスを少し読んで作ります。だから、別の更新意志のバグ出しを選択

   注意事項：SQL読み込みする必要があります更新アカウントセットバランス=バランス-50、ID = 1。

    

    

    

    

   反復の言葉を読んで、良いですが、スナップショットの読み取り（バージョン履歴）で、挿入、更新、および優れた更新されたバージョンを削除し更新していないバージョンを選択し、現在の測定値（現在のバージョン）であります

   だから、更新後の再オープンファントム読み取り現象がある可能性があります調査を：

    

   セッション1：アカウントから選択します*;

   セッション2：アカウントへの挿入（名前、お金）の値（ 'SS'、100）;

   セッション1：アップデートアカウントのセット名= 'LYR' ID = 1;

   セッション1：アカウントから選択します*;

    

   セッション1場合：この表は、アカウントを更新していない、読んでます、ファントムは、スナップショットでは発生しません、問題を読みます

   しかし：セッション1：このフォームでアカウントを更新し、それがスナップショットの読みから現在の読み取りを変更します

   そして、この時間は、名前=「SS」、お金=データ100を挿入セッション2

   セッション1再びルックアップテーブル、これは（幽霊の登場）データの幻想のようなものですか理由を見つけます

   これは、ファントムのリード

    

   シリアルに、それが低いため効率が、問題ありませんが、そうすべきではありません

   汚れの問題を解決するために反復可能読み取りの両方できるだけ効率を使用してMySQLを読み込み、非反復読み取り

    

    

   MySQLの最近のデッドロックのログ情報を表示します。

   エンジンInnoDBのステータス\ Gを表示

    

    

   MySQLの最適化：

   1. 可能な限りように割り出して取得すべてのデータが完全であること、テーブルロックに非インデックス行ロックのエスカレーションを避けるために
   2. インデックスの合理的な設計、ロック範囲を最小限に抑えます
   3. 回避ギャップロックについての検索検索条件
   4. ロックされたリソースの量を減らすために、取引の大きさ、および時間の長さを制御するようにしてください
   5. トランザクション分離の可能な限り低いレベル

これは、並行性の問題を解決することができます

1. 更新アカウントセットお金=お金-1、ID =「llyr」とお金> 0。

 

MySQLは、ギャップをロックすることができ、その後、長距離MySQLは自動的にロックされ、それは一般的に問題ファントムリードありません

 

状態がロックアップする範囲、mysqlのです

これは、ファントム読み取りの問題を解決します

https://blog.csdn.net/spring_model/article/details/53992450

このようような更新のための排他ロックなどの他のロックがありますが、

 

トランザクションがリリース後に開いたロックは、COMMIT mysqlの更新ステートメント

だから、SQLいい、一般的ではない問題を記述します。