sql >> Databasteknik >  >> RDS >> Mysql

Varför är ett IX-lås kompatibelt med ett annat IX-lås i InnoDB?

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

Detta innebär att flera trådar kan få IX-lås. Dessa lås är på bordsnivå, inte på radnivå. Ett IX-lås betyder att tråden som håller det har för avsikt att uppdatera några rader någonstans i bordet. IX-lås är endast avsedda att blockera fullbordsoperationer.

Det kan kasta lite ljus om du anser att det går åt båda hållen -- om en fullbordsoperation pågår så har den tråden ett lås på bordsnivå som blockerar ett IX-lås.

DML-operationer måste först skaffa ett IX-lås innan de kan försöka låsa på radnivå. Anledningen är att du inte vill att DML ska tillåtas medan en ALTER TABLE pågår, eller medan någon annan tråd har gjort LOCK TABLES...WRITE .

Ändringar på radnivå som UPDATE , DELETE , SELECT..FOR UPDATE inte blockeras av ett IX-lås. De blockeras av andra radnivåändringar eller av ett faktiskt fullständigt tabelllås (LOCK TABLES , eller vissa DDL-satser). Men bortsett från dessa tabelloperationer, kan flera trådar som kör DML förmodligen fungera samtidigt, så länge som var och en arbetar på en uppsättning rader som inte överlappar varandra.

Angående din kommentar:

Den andra SELECT...FOR UPDATE är inte blockerad i väntan på IX-låset, den är blockerad i väntan på X-lås (radnivå) på rader som redan är låsta av X-lås i en annan tråd.

Jag provade precis detta och sedan körde jag SHOW ENGINE INNODB STATUS så jag kunde se den blockerade transaktionen:

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

Ser? Det står att den väntar på att få låset med lock_mode X på primärnyckelindexet i tabellen test . Det är ett lås på radnivå.

Återställ din förvirring om LOCK IN SHARE MODE :

Du pratar om tre nivåer av SELECT .

  • SELECT begär inga lås. Inga lås blockerar den, och den blockerar inga andra lås.
  • SELECT ... LOCK IN SHARE MODE begär ett IS-lås på bordet, och sedan låser S på rader som matchar indexsökningen. Flera trådar kan hålla IS-lås eller IX-lås på ett bord. Flera trådar kan hålla S-lås samtidigt.
  • SELECT ... FOR UPDATE begär ett IX-lås på tabellen, och sedan låser X på rader som matchar indexsökningen. X-lås är exklusiva vilket betyder att de inte kan någon annan tråd ha ett X-lås eller ett S-lås på samma rad.

Men varken X- eller S-lås bryr sig om IX- eller IS-lås.

Tänk på denna analogi:föreställ dig ett museum.

Många människor, både besökare och curatorer, kommer in på museet. Besökarna vill se målningar, så de bär ett märke märkt "IS". Kuratorerna kan byta ut målningar, så de bär ett märke märkt "IX". Det kan vara många människor i museet samtidigt, med båda typerna av märken. De blockerar inte varandra.

Under sitt besök kommer de seriösa konstfantasterna att komma så nära målningen de kan och studera den under långa perioder. De låter gärna andra konstfantaster stå bredvid dem inför samma målning. De gör därför SELECT ... LOCK IN SHARE MODE och de har "S"-lås eftersom de åtminstone inte vill att tavlan ska bytas ut medan de studerar den.

Kuratorerna kan ersätta en målning, men de är artiga mot de seriösa konstfantasterna, och de kommer att vänta tills dessa tittare är klara och gå vidare. Så de försöker göra SELECT ... FOR UPDATE (eller helt enkelt UPDATE eller DELETE ). De kommer att skaffa "X"-lås vid denna tidpunkt, genom att hänga upp en liten skylt som säger "utställningen omdesignas." De seriösa konstfantasterna vill se konsten presenterad på ett ordentligt sätt, med snygg belysning och lite beskrivande plack. De kommer att vänta på att omdesignen ska göras innan de närmar sig (de får en låsvänte om de försöker).

Dessutom har du förmodligen varit på ett museum där mer tillfälliga besökare vandrar omkring och försöker hålla sig ur andra människors väg. De tittar på målningar från mitten av rummet, inte närmar sig för nära. De kan titta på samma målningar som andra tittare tittar på, och de kan kika över axlarna på de seriösa konstfantasterna, för att också titta på de målningar som ses. De kanske till och med stirrar på kuratorerna medan de byter ut tavlor (de bryr sig inte om de skymtar en tavla som inte har monterats och belyst ordentligt än). Så dessa tillfälliga besökare blockerar inte någon, och ingen blockerar deras visning. De gör bara SELECT och de begär inga lås.

Men det finns också byggnadsarbetare som ska riva väggar och sånt, men de fungerar inte medan det är någon i byggnaden. De väntar på att alla ska gå och när de väl har börjat sitt arbete släpper de inte in någon. Det är så närvaron av antingen IS- och IX-märken blockerar DDL (byggnadsarbetet) och vice versa.



  1. Databas för fulltextsökning och 200 miljoner+ poster

  2. oracle Välj datum för varor som säljs inom 1 minut från varandra

  3. Kör/kör flera procedurer i Parallell - Oracle PL/SQL

  4. Hur Cotd() fungerar i PostgreSQL