sql >> データベース >  >> RDS >> Mysql

IXロックがInnoDBの別のIXロックと互換性があるのはなぜですか?

    https://dev.mysql.com/doc /refman/5.6/en/innodb-lock-modes.html 言う:

    これは、複数のスレッドがIXロックを取得できることを意味します。これらのロックは、行レベルではなく、テーブルレベルにあります。 IXロックは、それを保持しているスレッドがいくつかの行をどこかで更新しようとしていることを意味します。 テーブルで。 IXロックは、フルテーブル操作をブロックすることのみを目的としています。

    双方向であると考えると、ある程度の光が当たる可能性があります。フルテーブル操作が進行中の場合、そのスレッドには、IXロックをブロックするテーブルレベルのロックがあります。

    DML操作は、行レベルのロックを試行する前に、まずIXロックを取得する必要があります。その理由は、ALTER TABLEの実行中にDMLが許可されないようにするためです。 進行中、または他のスレッドがLOCK TABLES...WRITEを実行している間 。

    UPDATEのような行レベルの変更 、DELETESELECT..FOR UPDATE IXロックによってブロックされていません。これらは、他の行レベルの変更、または実際の完全なテーブルロック(LOCK TABLES)によってブロックされます。 、または特定のDDLステートメント)。ただし、これらのテーブル操作とは別に、DMLを実行している複数のスレッドは、それぞれが重複しない行のセットで動作している限り、おそらく同時に動作できます。

    コメントを再確認してください:

    2番目のSELECT...FOR UPDATE IXロックの待機はブロックされません。別のスレッドのXロックによってすでにロックされている行のX(行レベル)ロックの待機はブロックされます。

    これを試した後、SHOW ENGINE INNODB STATUSを実行しました ブロックされたトランザクションを確認できました:

    ---TRANSACTION 71568, ACTIVE 12 sec starting index read
    mysql tables in use 1, locked 1
    LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
    MySQL thread id 10, OS thread handle 140168480220928, query id 288 localhost root statistics
    select * from test where id=1 for update
    ------- TRX HAS BEEN WAITING 12 SEC FOR THIS LOCK TO BE GRANTED:
    RECORD LOCKS space id 802 page no 3 n bits 72 index `PRIMARY` of table `test`.`test` 
    trx id 71568 lock_mode X locks rec but not gap waiting
    

    見る? 主キーインデックスのlock_modeXでロックが付与されるのを待っていると表示されます。 テーブルのtest 。これは行レベルのロックです。

    LOCK IN SHARE MODEについて混乱してください :

    あなたは3つについて話している SELECTのレベル 。

    • SELECT ロックを要求しません。ロックはそれをブロックせず、他のロックもブロックしません。
    • SELECT ... LOCK IN SHARE MODE テーブルのISロックを要求し、次にSがインデックススキャンに一致する行をロックします。複数のスレッドは、テーブルのISロックまたはIXロックを保持できます。複数のスレッドが同時にSロックを保持できます。
    • SELECT ... FOR UPDATE テーブルのIXロックを要求し、次にインデックススキャンに一致する行をXロックします。 Xロックは排他的です つまり、他のスレッドがXロックを設定することはできませんまたは 同じ行のSロック。

    ただし、XロックもSロックもIXロックやISロックを気にしません。

    この例えを考えてみてください。美術館を想像してみてください。

    来館者も学芸員も多くの人が美術館に入ります。来場者は絵画を見たいので、「IS」のバッジをつけています。キュレーターは絵画を置き換える可能性があるため、「IX」というラベルの付いたバッジを着用します。両方のタイプのバッジを持って、同時に多くの人々が美術館にいる可能性があります。お互いをブロックしません。

    彼らの訪問の間、真面目な芸術ファンは彼らができる限り絵に近づき、そしてそれを長い間研究するでしょう。彼らは同じ絵の前に他の芸術ファンを彼らの隣に立たせて喜んでいます。したがって、彼らはSELECT ... LOCK IN SHARE MODEを実行しています。 少なくとも、勉強中に絵を交換したくないので、「S」ロックが付いています。

    キュレーターは絵画を置き換えることができますが、彼らは真面目なアートファンに礼儀正しく、これらの視聴者が完成するまで待って次に進みます。そのため、彼らはSELECT ... FOR UPDATEを実行しようとしています。 (または単にUPDATE またはDELETE )。この時点で、「展示物が再設計されている」という小さなサインアップを掛けることで、「X」ロックを取得します。真面目な芸術ファンは、素敵な照明といくつかの説明的なプラークで、適切な方法で提示された芸術を見たいと思っています。再設計が完了するのを待ってからアプローチします(試行するとロック待機します)。

    また、あなたはおそらく、他の人の邪魔にならないように、よりカジュアルな訪問者がさまよっている美術館に行ったことがあるでしょう。彼らは部屋の真ん中から絵画を見て、近づきすぎないようにしています。彼らは他の視聴者が見ているのと同じ絵を見ることができ、真面目な芸術ファンの肩越しに覗いて、それらの絵も見られているのを見ることができます。彼らは絵画を交換している間、学芸員をじっと見つめることさえあります(彼らはまだ適切に取り付けられて照明されていない絵画を垣間見るかどうかは気にしません)。したがって、これらのカジュアルな訪問者は誰もブロックせず、誰も彼らの視聴をブロックしません。彼らはただSELECTをしているだけです そして、彼らはロックを要求しません。

    しかし、壁などを壊すはずの建設作業員もいますが、建物の中に誰かがいる間は作業しません。彼らは全員が去るのを待ちます、そして彼らが彼らの仕事を始めると、彼らは誰も入れません。それはISとIXバッジのどちらかの存在がDDL(建設工事)をブロックする方法です。>>

    1. Postgresで暗号化されたフィールドを検索しています

    2. Postgresウィンドウは集計グループbyで機能します

    3. OracleでY/N列にインデックスを付ける方法

    4. Oracle / PLSQLでNULL値のみをカウントするにはどうすればよいですか?