この記事では、MySQL の 2 段階ロックとデッドロックを中心に、MySQL ロックに関する関連知識を紹介します。一緒に見ていきましょう。皆様のお役に立てれば幸いです。
コンセプト
では、 InnoDB
が行ロックのロックとロック解放の動作をどのように処理するかについて説明します。
トランザクションの使用中に、主キーに基づいてレコードが削除されると、排他ロックが 直ちに追加され、ロック#が完了します。 ##ステージ。
削除アクションが完了しても、ロックはすぐには解放されず、トランザクションがコミットされるまでロックは解放されます。
発生した問題 - ブロックトランザクション A | トランザクション B |
---|---|
begin;update t set k=k 1 where id=1; update t set k=k 1 where id= 2 ; |
|
update t set k=k 2 where id= 1; |
|
# のデータにより、トランザクション B は ## になります。次のステップに進む前に トランザクション B
がロックを取得する必要があるため、トランザクション A
はロックされブロックされています。
上記の問題は大きな問題ではないように思えるかもしれませんが、トランザクション B
だけでなく、トランザクション C、
トランザクション B と同じことを行うと、問題は大きくなり、ブロックされるスレッドがさらに多くなります。 [推奨される学習:
MySQL ビデオ チュートリアル ]
上記の問題に対処する方法
ブロックを引き起こす可能性のあるステートメントをファイルの最後に配置するように最善を尽くす必要があります。上記の
Transaction A の例のステートメント id=1
**ホット行**) ) ですが、トランザクションの開始時にロックを取得するわけではありません。
本質的に、ロックの取得からロックの解放までの時間が短縮されます。つまり、ロックの保持時間が短縮され、ロックによるブロッキングが軽減される。
デッドロック
コンセプト
2 つのスレッドが互いにリソースを解放するのを待っています。 2 つのトランザクション A と B。
トランザクション A
はリソース A
のロックを取得しました。 トランザクション B
は
リソース B
トランザクション A
は、
リソース B
トランザクション B
は、
リソース A
明らかに、ステップ 3 と 4 では、トランザクション A と B は両方ともロックを取得したいと考えていますが、相手がリソースのロックを解放していないため、どちらもロックを取得できません。この現象はデッドロックです。
発生した問題 - デッドロック
InnoDB
では、ロック取得の待ち時間の設定があり、この時間を超えるとエラーが発生します。例外として、この時間のデフォルトは50 秒です。一般に、応答に 50
秒かかるインターフェイスは受け入れられません。innodb_lock_wait_timeout。
設定時間を短く設定するだけで十分ですか?たとえば、
1 秒ですか?
通常のビジネスに影響を与える可能性があるため、不可能であるはずです。おそらく、ビジネスによってトランザクションの実行時間が比較的長くなり、
1
上記問題の対処方法
InnoDB
CPU を消費します。
原理は、トランザクションがロックされようとしているときに、他の同時スレッドがこのリソースをロックしているかどうかを検出するというものです。特定の スレッド A がロックしていることが検出された場合は、再び会合します。
スレッド A の依存関係が他の同時スレッドによってロックされているかどうかなどを検出し、最終的にこれらのロックがデッドロックを形成するかどうかを判断します。
innodb_deadlock_detect。
個人的な現在の学習に基づいたこの問題の処理と概要のみを表します:
15 秒を超えないでください。
15
Mysql 接続数を制御し、## の最大数を制限します。 #Mysql
サービス層での接続。 上記は、行ロックによるパフォーマンスへの影響を軽減する方法の概要です。
以上がMySQL の 2 フェーズ ロックとデッドロックについて話しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。