免責事項：この記事はブロガーオリジナル記事ですが、許可ブロガーなく再生してはなりません。https://blog.csdn.net/wrs120/article/details/91046701

ロックについてのMySQLの知識、ブログ記事を参照してください。https://blog.csdn.net/wrs120/article/details/86566879は、上記した説明では、知っているInnoDBストレージエンジンは、主に以下のInnoDBストレージエンジンのために、行ロックをサポートしています行ロックを説明します。

1.ロックカテゴリ

1.1共有ロック（Sロック）

これは、複数のトランザクションが同じ行のデータを読み取ることができます

1.2排他ロック（Xロック）

トランザクションが同じデータ行を削除または更新することを可能にします

	バツ	S
バツ	互換性がありません	互換性がありません
S	互換性がありません	コンパチブル

InnoDBは問題が存在するテーブル・レベルとローレベルのロックのロックを可能にする、マルチ粒度ロックをサポート。異なる粒度ロックの操作をサポートするために、InnoDBストレージエンジンと呼ばれる追加のロックモード、サポート意図ロック。意図的ロックは、複数のレベルにオブジェクトをロックすることを意味し、意図的ロック手段は、よりきめ細かにでロックします。意図テーブルレベルでロックするロックが、それは、トランザクションがリードであるか、または全体ではなく、テーブルの行のレコードを書き込むことを意味するので、意図ロックの間には競合し、行に残業行ロックの本当の競合をチェックロックする前に、最初は、この表に加えて意図的ロックを与えます。また、意図同時にテーブルと行ロックを追加すること、に分割されます。

意図共有ロック（ISロック）：トランザクションは、テーブルの上に共有ロックの数行を取得したいです
意図排他ロック（IXロック）：トランザクションが表の行にロックの数行を取得したいです

しかし、InnoDBはその意図的ロックは、予想外の全表スキャンを除くすべての要求をブロックするつもりはない、行レベルロックをサポートしています。

	IS	IX	S	バツ
IS	コンパチブル	コンパチブル	コンパチブル	互換性がありません
IX	コンパチブル	コンパチブル	互換性がありません	互換性がありません
S	コンパチブル	互換性がありません	コンパチブル	互換性がありません
バツ	互換性がありません	互換性がありません	互換性がありません	互換性がありません

1.3意図的ロック

なぜ意図的ロックは、それはありますか？？？
最初の例：

テーブル内のロックされたトランザクションの行は、行のみ読むことができるように、書くことができません。
トランザクションBは、テーブル全体に書き込みロックを適用します。
トランザクションBアプリケーションが成功した場合、理論的には、行ロック競合を保持するテーブルの任意の行を変更することができるであろう。
データベースは、アプリケーションBは、行ロックの解除までブロックさせ、このような競合を回避する必要があります。

データベースには、どのようにこの競合にそれを決定するには？

STEP1：表が表ロックテーブルで他のトランザクションによって使用されているか否かを決定します
STEP2：表の各行は、ロックが行をロックしたか否かを判断します

注STEP2、効率を決定するためのそのような方法があるため、テーブル全体を横断する必要性、高くありません。そして、ロックする意図があります。意図の存在下で最初に成功したアプリケーションの行ロック行の後に、テーブルの上に意図的共有ロックを適用しなければならないトランザクションをロック。意図的ロックの存在下で、上記の決意を変えることができます

STEP1：変わらず
STEP2：表は、いくつかの行がロックされた共有行ロックであることを示し、テーブル上の意図共有ロックを見つけ、したがって、トランザクションB申込書書き込みロックがブロックされます。

注意：ロック操作を適用する意思が完全なデータベースである、つまり、取引行がアプリケーションの行をロックする場合、データベースは自動的に適用する意思の開始前にテーブルをロックします、我々は、プログラマが適用するためにコードを使用する必要はありません。

要約：表レベルのロックと行レベルのロッキングの間の競合の検出を容易にするために、意図的ロックの導入に

1.4ノンロックは、読取り一貫性

InnoDBは、行およびバージョニング（MVCC）のようにして、データベース内の現在の行データの実行時間を読み取ることを意味し、そのような行がDELETEまたはUPDATE操作読み出され、線X-ロックで待機しませんこの時点で読み出し動作リリース、データのスナップショット、データのスナップショットのラインを読みますがUNDOセグメントを通過しますが行われ、データが使用中なので、長いトランザクションの実装が生成するよう、確かにデータを元に戻す生じるであろう時にトランザクションをロールバックするために使用されて元に戻す、使用スナップショットデータは、追加のオーバーヘッドがなく、スナップショットトランザクションを変更していない間、それはロック動作を行う際にこのデータにアクセスすることができない
各行のInnoDBのスナップショットは、複数のバージョンを有することができるので、マルチラインバージョン技術と呼ばれますこの技術になるで同時実行制御、マルチバージョン同時実行制御（MVCC）。READ COMMITTEDとREPEATABLE READトランザクション分離レベルでは、InnoDBが一貫した非ロックリードを使用して、その差が、READ COMMITTEDトランザクション分離レベルであり、スナップショットデータ一貫性非ロック読み取りが常にロックされている最新のデータを読み出しますスナップショットデータのコピー、および反復可能読み取りトランザクション分離レベルでは、非ロックのスナップショットのデータは、一貫性が常にスタートラインを読み込む読んだときに、データのバージョン総務

1.5一貫性はロックを読みます

明示的なユーザは、いくつかの場合には、ロック操作を実行するデータベースを読み取る必要があるステートメントをロックすることによって達成することができるデータの整合性のロジックを確保するように動作します。

SELECT … FOR UPDATE（X锁）; SELECT … LOCK IN SHARE MODE（S锁）;

これらの記述は自動的に解除されますトランザクションがロックをコミット、トランザクションで使用することができます。偶数行がそのように明示的にロックされていることに注意してください、それ以外の事項一貫非ロック読み取りは、スナップショットデータのバージョンを読むことです。

1.6成長とセルフロック

成長のための主キーので、InnoDBは挿入のパフォーマンスを向上させ、特別なテーブルロック機構オート株式会社ロックを使用しますが、ロックは、トランザクションが完了した後までリリースしたが、SQLへの自己成長値の完了後すぐに解放されません。

1.7外部キーとロック

明示的に列インデックスに追加されていない場合は、外部キー列の場合、InnoDBは自動的にインデックスがロックテーブルを避けるために、添加されます。外部キーの必要性では、あなたが最初に親テーブルSELECTでレコードを挿入または更新する必要があります、SELECTは、この時点で使用することはできません、それはSELECTを使用して、本質的に、この時点で一貫性のないデータの問題が発生する可能性があるため、道の一貫非ロック読み取りです...共有モードでロック、つまりSが自動的に行のトランザクションの実行を防止するためにロックを追加する削除または変更され、これはまた、インデックスが外部キー必要性を追加することが有用であることを示しています。

2.ロックアルゴリズム

2.1レコードのロック

行ロックは、単一のライン上のレコードロックは、アルゴリズムは常にロックするインデックスレコードを InnoDBストレージエンジンは、暗黙主キーロックを使用して、今回の作成任意のインデックステーブルを備えていない場合、

2.2ギャップロック

ギャップロック、ロック範囲が、記録そのものが含まれていません

2.3次、キーロック

録音ロックとギャップロックを組み合わせた一時的なロック、クエリのInnoDBの行は、このロックを使用しているが、とき、インデックスがユニークインデックスがあるとき、次のキーロックのためのレコードのロックダウングレード
REPEATABLEでネクストキーロックREADものをファントム問題ファントムを解決する分離レベルの下問題読み出す（同じことを意味するファントムの問題、SQL文の同じ2回の連続する実行が異なる結果をもたらすことができる前に、SQLの第二は、返すことができる全く存在しないライン）が、特定のなお、ファントム行が同じデータを変更する必要が存在し、ないていない読み取るための手段を読んで、次のキーロックが解決ファントムが問題を読んで、なぜ、最初のトランザクション分離レベルは、READ COMMITTEDに設定を示しています。

時間	セッション1	セッション2
1	設定されたセッションtx_isolation = 'READ-省略さ' を
2	ベギン;
3	4：更新返回のために> 2トンから選択*
4		ベギン;
5		T挿入4を選択します。
6		コミット;
7	T SELECT * FROM場合> 2更新用返回：4：5	T挿入4を選択します。

トランザクションは、ファントムの出現で見つけることができ、第二読会以上を読み取ります。このデータを5。しかし、トランザクション分離レベルをREPEATABLE READに設定されている、祝うために表示されないため、実行セレクト*> 2については、ロックされた場合（2、+∞）の更新は、この範囲が追加されたXロック、さらに業務の第からインサート5 Xロックを得ることができない実行し、それだけでブロックすることができます。

InnoDBストレージエンジンは、挿入操作のために、次のレコードの挿入レコードが既にロックされている場合、クエリが許可されていない、ロックされてチェックされます。

3.ロックの問題

トランザクションが作業を複雑にすることができるように、トランザクション分離要件を達成するためのロックが、しかし、いくつかの潜在的な問題があります。ロックは、次の3つの質問をもたらすでしょう。

3.1ダーティリード

他のデータは、データベースのトランザクション分離の要件に違反して、コミットされていないトランザクションを読んで、この問題はコミットレベルを読むトランザクション分離レベルを設定しません。この問題を解決することができるようになります

3.2非反復可能読み取り

同じデータセットへのトランザクションで何回も読むが、結果は読書と同じではありません。この問題は、トランザクションの分離レベルは、この問題を解決するネクストキーロックの反復使用を読むために、コミット読むに発生し
たデータは、ダーティリードコミットされていない、非反復可能読み取りが送信されたデータを読み取ることで読み込まれますが、データベースに違反してトランザクションの一貫性の要件

ロジックに3.3アップデートを失いました

4.デッドロック

4.1コンセプト

現象は、互いの待ち時間によって引き起こされるリソースの競合のために、実装プロセス内の2つの以上のトランザクションを指し、

4.2デッドロックの検出と解決策

タイムアウト：、しきい値を設定した時間がこのしきい値を超える待って、ロールバックするトランザクションの1つ、別のトランザクションが実行を継続できるようにしますが、タイムアウト企業は重量を占め問題があるが、このようなトランザクション操作の更新として、比較的大きいです時間は、より多くのログを元に戻す取り上げ、多くの、多くのラインよりも相対的に別のトランザクションを話すトランザクション時間をロールバックします
図ループはプルーフ、深さ優先アルゴリズムのバージョンが1.2の前に、1.2デッドロック検出が最適化された、非再帰再帰的方法、ロールバック最下アンドゥ量をデッドロックが存在するか否かを検出し、待ちグラフを待っ業務

InnoDBストレージエンジンは、デッドロックを除き、エラー例外のほとんどをロールバックしません。彼らはデッドロックを見つけた場合、InnoDBはすぐにトランザクションをロールバックします

5.ロックのエスカレーション

そこロックエスカレーションSQL Serverデータベースですが、InnoDBストレージエンジン、ロック・エスカレーションは存在しません。それは使用して、各ページのロックトランザクション管理へのアクセスのそれぞれに応じて、逆に、各レコードに応じて行ロックを生成していないため、モードビットマップを。この時点でテーブル全体が30バイトを占め、各ページが格納さローブのロック情報を更新する場合300万は、データ・ページの表、各ページデータ100 300万のレコードの総数を有し、そのオブジェクトのみが90メガバイトでありますメモリ、この状況が発生していない、ロックはメモリ占有3ギガバイト上のすべてのロック、10バイトを占有します

[ロック] MySQLのInnoDBストレージエンジン

記事のディレクトリ