Mysql
 sql >> Base de données >  >> RDS >> Mysql

Pourquoi un IX-lock est-il compatible avec un autre IX-lock dans InnoDB ?

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

Cela signifie que plusieurs threads peuvent acquérir des verrous IX. Ces verrous sont au niveau de la table, pas au niveau de la ligne. Un verrou IX signifie que le thread qui le détient a l'intention de mettre à jour certaines lignes quelque part dans la table. Les verrous IX sont uniquement destinés à bloquer les opérations de table complète.

Cela peut vous éclairer si vous considérez que cela va dans les deux sens - si une opération de table complète est en cours, alors ce thread a un verrou au niveau de la table qui bloque un verrou IX.

Les opérations DML doivent d'abord acquérir un verrou IX avant de pouvoir tenter des verrous au niveau de la ligne. La raison est que vous ne voulez pas que DML soit autorisé pendant qu'un ALTER TABLE est en cours, ou alors qu'un autre thread a fait LOCK TABLES...WRITE .

Modifications au niveau de la ligne comme UPDATE , DELETE , SELECT..FOR UPDATE ne sont pas bloqués par une serrure IX. Ils sont bloqués par d'autres modifications au niveau de la ligne ou par un véritable verrou de table complet (LOCK TABLES , ou certaines instructions DDL). Mais en dehors de ces opérations de table, plusieurs threads exécutant DML peuvent probablement fonctionner simultanément, tant qu'ils travaillent chacun sur un ensemble de lignes qui ne se chevauchent pas.

Concernant votre commentaire :

Le deuxième SELECT...FOR UPDATE n'est pas bloqué en attente sur le verrou IX, il est bloqué en attente sur les verrous X (au niveau de la ligne) sur des lignes déjà verrouillées par des verrous X dans un autre thread.

Je viens d'essayer ceci, puis j'ai exécuté SHOW ENGINE INNODB STATUS afin que je puisse voir la transaction bloquée :

---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

Voir? Il dit qu'il attend de se voir accorder le verrou avec lock_mode X sur l'index de clé primaire du tableau test . C'est un verrou au niveau de la ligne.

Re votre confusion à propos de LOCK IN SHARE MODE :

Vous parlez de trois niveaux de SELECT .

  • SELECT ne demande pas de verrous. Aucun verrou ne le bloque, et il ne bloque aucun autre verrou.
  • SELECT ... LOCK IN SHARE MODE demande un verrou IS sur la table, puis S verrouille les lignes qui correspondent au parcours d'index. Plusieurs threads peuvent contenir des verrous IS ou IX sur une table. Plusieurs threads peuvent contenir des verrous S en même temps.
  • SELECT ... FOR UPDATE demande un verrou IX sur la table, puis X verrouille les lignes qui correspondent au parcours d'index. Les serrures X sont exclusives ce qui signifie qu'aucun autre thread ne peut avoir un verrou X ou un verrou S sur la même ligne.

Mais ni les verrous X ni S ne se soucient des verrous IX ou IS.

Pensez à cette analogie :imaginez un musée.

De nombreuses personnes, visiteurs et conservateurs, entrent dans le musée. Les visiteurs veulent voir des peintures, ils portent donc un badge portant la mention "IS". Les conservateurs peuvent remplacer les peintures, ils portent donc un badge portant la mention "IX". Il peut y avoir plusieurs personnes dans le musée en même temps, avec les deux types de badges. Ils ne se bloquent pas.

Au cours de leur visite, les amateurs d'art sérieux se rapprocheront le plus possible de la peinture et l'étudieront pendant de longues périodes. Ils sont heureux de laisser d'autres amateurs d'art se tenir à côté d'eux devant le même tableau. Ils font donc SELECT ... LOCK IN SHARE MODE et ils ont des verrous "S" parce qu'ils ne veulent pas au moins que le tableau soit remplacé pendant qu'ils l'étudient.

Les conservateurs peuvent remplacer un tableau, mais ils sont courtois envers les amateurs d'art sérieux, et ils attendront que ces spectateurs aient terminé et passent à autre chose. Ils essaient donc de faire SELECT ... FOR UPDATE (ou bien simplement UPDATE ou DELETE ). Ils acquerront des serrures "X" à ce moment-là, en accrochant une petite pancarte disant "exposition en cours de refonte". Les amateurs d'art sérieux veulent voir l'art présenté de manière appropriée, avec un bel éclairage et une plaque descriptive. Ils attendront que la refonte soit terminée avant d'approcher (ils obtiendront un verrou d'attente s'ils essaient).

De plus, vous avez probablement été dans un musée où des visiteurs plus occasionnels se promènent, essayant de rester à l'écart des autres. Ils regardent les peintures du milieu de la pièce, sans trop s'approcher. Ils peuvent regarder les mêmes peintures que les autres spectateurs regardent, et ils peuvent jeter un coup d'œil par-dessus les épaules des amateurs d'art sérieux, pour regarder ces peintures également. Ils peuvent même regarder les conservateurs pendant qu'ils remplacent les peintures (ils ne se soucient pas s'ils aperçoivent une peinture qui n'a pas encore été montée et éclairée correctement). Ainsi, ces visiteurs occasionnels ne bloquent personne et personne ne bloque leur visionnage. Ils font juste SELECT et ils ne demandent aucun verrou.

Mais il y a aussi des ouvriers du bâtiment qui sont censés abattre des murs et tout, mais ils ne travailleront pas tant qu'il y aura quelqu'un dans le bâtiment. Ils attendront que tout le monde parte, et une fois qu'ils auront commencé leur travail, ils ne laisseront entrer personne. C'est ainsi que la présence des badges IS et IX bloquent DDL (les travaux de construction), et vice-versa.