web-dev-qa-db-ja.com

DBロックは接続とセッションにどのように関連付けられていますか？

ページレベルおよび行レベルのロックについて聞いたことがありますが、セッションおよび接続に関してそれらが使用されるのを聞いたことがありません。今日、（MySQL）DBAは行ロックについて話していましたが、それらのスコープは接続またはセッションレベルで設定できることを暗示していました。これは本当ですか、それとも私は彼を誤解しましたか？

接続が確立されたとき（またはセッションが開始されたとき）にロックが設定され、その接続/セッションが終了したときにロックが解除されることを知りませんでした。これに該当する場合、行/ページレベルのロックよりもどのような利点がありますか？前もって感謝します。

mysqlinnodblockingsession
3
Mara

ある程度、そうです。

InnoDBに関しては、ロックできる行を選択できます。これは、DB接続の特定の設定ではありません。これは、UPDATEを実行する前に呼び出す必要がある特定のクエリです。

  • SELECT ... FOR UPDATE
  • SELECT ... LOCK IN SHARE MODE

これにより、これらのSELECTの結果セットに基づいて、排他的または共有の行ロックを開始できます。

これに関する詳細は MySQL Documentation にあります。

私はこれらを使用して以前の投稿を書きました：

セッションと接続について

  • SELECT ... FOR UPDATEを実行すると、更新する行のロックが開始され、他のDB接続による読み取りが許可されます。
  • SELECT ... LOCK IN SHARE MODEを実行すると、本質的に逆のことが行われます
    • あなたが読めるように行をロックする
    • 同じロックされた行のSELECTを許可する
    • 接続がSELECT ... FOR UPDATEまたは直接DMLを実行しないようにする

これらのSELECTクエリを使用することで私が目にする唯一の利点は、ページでの不要なデッドロックを防ぐことです。

これが役に立てば幸いです!!!

2
RolandoMySQLDBA

これに該当する場合、行/ページレベルのロックよりもどのような利点がありますか？

彼の意味を誤解しているかもしれません。

クライアント接続とセッションは本質的に同じものです。セッションは、クライアントの認証後に開始され、クライアントが切断すると終了します。 （これらはドキュメントではスレッドとも呼ばれます。各接続/セッションには通常、それを処理する専用のサーバースレッドがあります。）

MySQLのすべてのロック- 行ロック 、 テーブルロック 、および 名前付きロック （これらはデータ構造ロックではなく、助言的mutexです）-ですロックを作成したセッションに常に関連付けられ、保持されます。

次のステートメントは、テーブルレベルのロックに関するMySQLのドキュメントからの抜粋ですが、すべてのロックに当てはまります。

セッションは、それ自体のロックのみを取得または解放できます。 1つのセッションが別のセッションのロックを取得したり、別のセッションが保持しているロックを解放したりすることはできません。

明示的に解放されない場合、ロックを保持しているセッションが終了すると、すべてのロックが常に自動的に解放されます。セッションは、クライアントが切断するか、クライアントスレッドが killed になるか、または interactive_timeout または wait_timeout タイマーはセッションに適用されます。

したがって、これらの意味で、ロックはセッションに「スコープ」されていると言えるでしょう。ただし、ロックのスコープと影響は常にグローバルです。それが当てはまらない場合は、ロックすることにあまり意味がありません。これは、他のセッションがスレッドの動作と競合することをしないようにするために正確に存在します。

InnoDBは、レコードロックとテーブル全体のロックの共存を可能にする複数の粒度のロックをサポートしています。複数の粒度レベルでのロックを実用的にするために、意図的ロックと呼ばれる追加のタイプのロックが使用されます。インテンションロックは、InnoDBのテーブルロックです。意図的ロックの背後にある考え方は、トランザクションが、そのテーブルの行に対して後で必要になるロックのタイプ（共有または排他）を示すことです。 — http://dev.mysql.com/doc/refman/5.5/en/innodb-lock-modes.html

これはSELECT ... LOCK IN SHARE MODE（「意図共有」行ロックを取得）およびSELECT ... FOR UPDATE（ "Intention Exclusive"行ロックを取得）ステートメント。行のロックを意図的に取得することができます...しかし、正確には、これらはセッションレベルではなく、さらに詳細です。セッションのサブセットであるトランザクションレベル。現在のトランザクションをCOMMITまたはROLLBACKするとすぐに、これらは解放されます。もちろん、セッションが予期せず終了した場合、トランザクションはロールバックされ、ロックも解放されます。

2
Michael - sqlbot