MySQLロックモード

11304 ワード
mysql
InnoDB  implements standard row-level locking where there are two types of locks,  shared ( S ) locks  and  exclusive ( X ) locks . For information about record, gap, and next-key lock types, see  Section 14.3.5.6, “ InnoDB  Record, Gap, and Next-Key Locks” .
InnoDBは標準的な行レベルロックを実現し、彼はまた2種類のロック、共有(S)ロックと排他(X)ロックを実現した.レコード、gap、next-keyロックタイプを参照する必要があります.xxxを参照してください.
A  shared ( S ) lock  permits the transaction that holds the lock to read a row.
  • 共有ロックにより、トランザクションがロックを取得して1行
    • を読み出すことができる.
    An  exclusive ( X ) lock  permits the transaction that holds the lock to update or delete a row.
  • 排他的ロックにより、トランザクションがロックを取得して、1行
    • を更新または削除することができる.
    If transaction  T1  holds a shared ( S ) lock on row  r , then requests from some distinct transaction  T2  for a lock on row  r  are handled as follows:
    トランザクションT 1が行rに対するSロックを持っている場合、他のトランザクションT 2の行rに対するロック要件は、次のように処理される.
    A request by  T2  for an  S  lock can be granted immediately. As a result, both  T1  and  T2  hold an  S  lock on  r .
  • T 2のSロックに対する要求はすぐに授権される.したがって、T 1 T 2は、rに対して共有ロック
    • を有する.
    A request by  T2  for an  X  lock cannot be granted immediately.
  • T 2のXロックに対する要求は、すぐに
    • に許可されない.
    If a transaction  T1  holds an exclusive ( X ) lock on row  r , a request from some distinct transaction  T2  for a lock of either type on  r  cannot be granted immediately. Instead, transaction  T2  has to wait for transaction  T1  to release its lock on row  r .
    トランザクションT 1がrのXロックを有する場合、T 2のrに対するロックタイプはすぐに許可することができない.代わりにT 2はT 1がr上のロックを解放するのを待たなければならない.
    Intention Locks
    意向ロック
    Additionally,  InnoDB  supports multiple granularity locking which permits coexistence of record locks and locks on entire tables. To make locking at multiple granularity levels practical, additional types of locks called  intention locks are used. Intention locks are table locks in  InnoDB  that indicate which type of lock (shared or exclusive) a transaction will require later for a row in that table. There are two types of intention locks used in  InnoDB  (assume that transaction  T  has requested a lock of the indicated type on table  t ):
    また、InnoDBは多重粒度ロックをサポートする、これにより行ロックとテーブルが共存する.多重粒度ロックに実用性を持たせるために、もう一つの意向ロックというロックが使用する.意向ロックはInnoDBでテーブルロックであり、SまたはXロックが1つのトランザクションで1つのローに使用されることを示している.InnoDBには2つの意向ロックがある(トランザクションTがテーブルtのロックを要求したと仮定する)
    Intention shared  ( IS ): Transaction  T  intends to set  S  locks on individual rows in table  t .
  • 意向共有ロック(IS):トランザクションTはSロックをテーブルt上の
    • に設定する予定である.
    Intention exclusive  ( IX ): Transaction  T  intends to set  X  locks on those rows.
  • 意向排他ロック(IX):トランザクションTは、行
    • にXロックを設定するつもりです.
    For example,  SELECT ... LOCK IN SHARE MODE  sets an  IS  lock and  SELECT ... FOR UPDATE  sets an  IX lock.
    例えばSELECT...LOCK IN SHARE_MODEはISロックを設定し、SELECTは...FOR UPDATE IXロックを設定する
    The intention locking protocol is as follows:
    意向ロックプロトコルは以下の通りです.
    Before a transaction can acquire an  S  lock on a row in table  t , it must first acquire an  IS  or stronger lock on  t .
  • トランザクションがテーブルtのローのSロックを取得する前に、テーブルtのISロックまたはより強いロック
    • を取得する必要がある.
    Before a transaction can acquire an  X  lock on a row, it must first acquire an  IX  lock on  t .
  • トランザクションがテーブルtの行のXロックを取得する前に、彼はtのIXロック
    • を取得しなければならない.
    These rules can be conveniently summarized by means of the following lock type compatibility matrix.
    これらの規則は,以下のロックタイプ互換行列にまとめることができる.
     X IX S IS X
    Conflict
    Conflict
    Conflict
    Conflict IX
    Conflict
    Compatible
    Conflict
    Compatible S
    Conflict
    Conflict
    Compatible
    Compatible IS
    Conflict
    Compatible
    Compatible
    Compatible
    A lock is granted to a requesting transaction if it is compatible with existing locks, but not if it conflicts with existing locks. A transaction waits until the conflicting existing lock is released. If a lock request conflicts with an existing lock and cannot be granted because it would cause  deadlock , an error occurs.
    1つのロックが既存のロックと互換性がある場合は、要求されたトランザクションに権限を与えることができますが、既存のロックと互換性がない場合はできません.トランザクションは、競合するロックが解放されるまで待たなければならない.ロック要求が既存のロックと衝突し、許可されない場合、デッドロックが発生する.
    Thus, intention locks do not block anything except full table requests (for example,  LOCK TABLES ... WRITE ). The main purpose of  IX  and  IS  locks is to show that someone is locking a row, or going to lock a row in the table.
    したがって、意図ロックは、テーブル全体の要求(例えば、LOCK TABLES...WRITE)でない限り、何もブロックすることはない.IXとISロックの主な目的は、誰かが1行をロックしているか、1行をロックしようとしていることを示す.
    Deadlock Example
    デッドロックの例
    The following example illustrates how an error can occur when a lock request would cause a deadlock. The example involves two clients, A and B.
    以下の例では、1つのロック要求によりデッドロックが発生する場合にエラーが発生する場合を例示する.例は、2つのクライアントA,Bを含む
    First, client A creates a table containing one row, and then begins a transaction. Within the transaction, A obtains an  S  lock on the row by selecting it in share mode:
    まず、クライアントAは、1行分のテーブルを作成する、トランザクションを開始する.トランザクション内で、Aはselect in share modeによってSロックを取得しました.
    mysql> CREATE TABLE t (i INT) ENGINE = InnoDB;
Query OK, 0 rows affected (1.07 sec)

mysql> INSERT INTO t (i) VALUES(1);
Query OK, 1 row affected (0.09 sec)

mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM t WHERE i = 1 LOCK IN SHARE MODE;
+------+
| i    |
+------+
|    1 |
+------+
1 row in set (0.10 sec)

    Next, client B begins a transaction and attempts to delete the row from the table:
    次にBはトランザクションを開始し、そのローを削除しようとします.
    mysql> START TRANSACTION;
Query OK, 0 rows affected (0.00 sec)

mysql> DELETE FROM t WHERE i = 1;

    The delete operation requires an  X  lock. The lock cannot be granted because it is incompatible with the  S  lock that client A holds, so the request goes on the queue of lock requests for the row and client B blocks.
    削除操作はXロックを取得しますが、ロックは許可されません.彼はAが持っているSロックと互換性がないため、要求が継続し、Bがブロックされます.
    Finally, client A also attempts to delete the row from the table:
    最後に、Aもこのローをテーブルから削除しようとします.
    mysql> DELETE FROM t WHERE i = 1;
ERROR 1213 (40001): Deadlock found when trying to get lock;
try restarting transaction

    Deadlock occurs here because client A needs an  X  lock to delete the row. However, that lock request cannot be granted because client B already has a request for an  X  lock and is waiting for client A to release its  S  lock. Nor can the  S  lock held by A be upgraded to an  X  lock because of the prior request by B for an  X  lock. As a result, InnoDB  generates an error for one of the clients and releases its locks. The client returns this error:
    デッドロックはここで発生した.Aはこの行を削除するためにXロックが必要だからだ.しかし、BはすでにXロックを要求する、AがSロックを解放するのを待っているため、Xロックを取得することができない.同じAのSロックもXロックにアップグレードできない.Bの前のリクエストがXロックを要求したからだ.これにより、InnoDBは、クライアントの1つに対してエラーを生成するロックを解除する.エラーは次のとおりです.
    ERROR 1213 (40001): Deadlock found when trying to get lock;
try restarting transaction

    At that point, the lock request for the other client can be granted and it deletes the row from the table.
    その場合、他のクライアントのロック要求が許可され、テーブルからローが削除されます.
    Note
    If the  LATEST DETECTED DEADLOCK  section of InnoDB Monitor output includes a message stating, “TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH, WE WILL ROLL BACK FOLLOWING TRANSACTION,”this indicates that the number of transactions on the wait-for list has reached a limit of 200, which is defined by LOCK_MAX_DEPTH_IN_DEADLOCK_CHECK . A wait-for list that exceeds 200 transactions is treated as a deadlock and the transaction attempting to check the wait-for list is rolled back.
    LATEST DETECTED DEADLOCKモニタが「TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH,WE WILL ROLL BACK FOLLOWING TRANSACION」というメッセージを出力した場合、待機リストのトランザクション数が200を超えたことを示します.これはLOCK_MAX_DEPTH_IN_DEADLOCK_CHECK定義待機リストが200トランザクションに達すると、デッドロックとみなされ、待機リストをチェックしようとするトランザクションがロールバックします.
    The same error may also occur if the locking thread must look at more than 1,000,000 locks owned by the transactions on the wait-for list. The limit of 1,000,000 locks is defined by LOCK_MAX_N_STEPS_IN_DEADLOCK_CHECK .
    菜鳥ing
    Mysql起動方式(4種類)