sql >> Database teknologi >  >> RDS >> Mysql

Hvorfor er en IX-lås kompatibel med en anden IX-lås i InnoDB?

https://dev.mysql.com/doc /refman/5.6/da/innodb-lock-modes.html siger:

Dette betyder, at flere tråde kan erhverve IX-låse. Disse låse er på bordniveau, ikke på rækkeniveau. En IX-lås betyder, at tråden, der holder den, har til hensigt at opdatere nogle rækker et sted i bordet. IX-låse er kun beregnet til at blokere fuldbordsoperationer.

Det kan kaste lidt lys, hvis du tænker på, at det går begge veje -- hvis en fuldbordsoperation er i gang, så har den tråd en lås på bordniveau, der blokerer en IX-lås.

DML-operationer skal først anskaffe en IX-lås, før de kan forsøge låse på rækkeniveau. Årsagen er, at du ikke ønsker, at DML skal tillades mens en ALTER TABLE er i gang, eller mens en anden tråd har lavet LOCK TABLES...WRITE .

Ændringer på rækkeniveau som UPDATE , DELETE , SELECT..FOR UPDATE er ikke blokeret af en IX-lås. De er blokeret af andre ændringer på rækkeniveau eller af en faktisk fuld tabellås (LOCK TABLES eller visse DDL-udsagn). Men bortset fra disse tabeloperationer, kan flere tråde, der kører DML, sandsynligvis fungere samtidigt, så længe de hver især arbejder på et sæt rækker, der ikke overlapper hinanden.

Om din kommentar:

Den anden SELECT...FOR UPDATE er ikke blokeret og venter på IX-låsen, den er blokeret og venter på X-låsene (rækkeniveau) på rækker, der allerede er låst af X-låse i en anden tråd.

Jeg har lige prøvet dette, og så kørte jeg SHOW ENGINE INNODB STATUS så jeg kunne se den blokerede transaktion:

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

Se? Den siger, at den venter på at blive tildelt låsen med lock_mode X på primærnøgleindekset i tabellen test . Det er en lås på rækkeniveau.

Gendan din forvirring om LOCK IN SHARE MODE :

Du taler om tre niveauer af SELECT .

  • SELECT anmoder om ingen låse. Ingen låse blokerer den, og den blokerer ingen andre låse.
  • SELECT ... LOCK IN SHARE MODE anmoder om en IS-lås på bordet, og derefter låser S på rækker, der matcher indeksscanningen. Flere tråde kan holde IS-låse eller IX-låse på et bord. Flere tråde kan holde S-låse på samme tid.
  • SELECT ... FOR UPDATE anmoder om en IX-lås på bordet, og derefter låser X på rækker, der matcher indeksscanningen. X-låse er eksklusive hvilket betyder, at de ikke kan nogen anden tråd have en X-lås eller en S-lås på samme række.

Men hverken X- eller S-låse bekymrer sig om IX- eller IS-låse.

Tænk på denne analogi:forestil dig et museum.

Mange mennesker, både besøgende og kuratorer, kommer ind på museet. De besøgende vil gerne se malerier, så de bærer et badge mærket "IS". Kuratorerne kan erstatte malerier, så de bærer et badge mærket "IX". Der kan være mange mennesker på museet på samme tid, med begge typer badges. De blokerer ikke hinanden.

Under deres besøg vil de seriøse kunstfans komme så tæt på maleriet, som de kan, og studere det i længere perioder. De er glade for at lade andre kunstfans stå ved siden af ​​dem før det samme maleri. De laver derfor SELECT ... LOCK IN SHARE MODE og de har "S"-låse, fordi de i det mindste ikke ønsker, at maleriet skal udskiftes, mens de studerer det.

Kuratorerne kan erstatte et maleri, men de er høflige over for de seriøse kunstfans, og de venter, indtil disse seere er færdige og går videre. Så de prøver at gøre SELECT ... FOR UPDATE (ellers blot UPDATE eller DELETE ). De vil erhverve "X" låse på dette tidspunkt ved at hænge et lille skilt op, hvor der står "udstillingen bliver redesignet." De seriøse kunstfans vil gerne se kunsten præsenteret på en ordentlig måde, med flot belysning og noget beskrivende plakat. De vil vente på, at redesignet er færdigt, før de nærmer sig (de får en låsevent, hvis de prøver).

Du har sikkert også været på et museum, hvor mere afslappede besøgende vandrer omkring og forsøger at holde sig væk fra andre menneskers måde. De ser på malerier fra midten af ​​rummet, og de kommer ikke for tæt på. De kan se på de samme malerier, som andre seere ser på, og de kan kigge over skuldrene på de seriøse kunstfans, for også at se på de malerier, der bliver set. De kan endda stirre på kuratorerne, mens de udskifter malerier (de er ligeglade med, om de skimter et maleri, der endnu ikke er blevet monteret og oplyst ordentligt). Så disse tilfældige besøgende blokerer ikke nogen, og ingen blokerer deres visning. De laver bare SELECT og de anmoder ikke om nogen låse.

Men der er også bygningsarbejdere, der skal rive vægge og sådan ned, men de vil ikke fungere, mens der er nogen i bygningen. De vil vente på, at alle går, og når de først begynder deres arbejde, vil de ikke lukke nogen ind. Det er sådan, at tilstedeværelsen af ​​enten IS- og IX-mærker blokerer DDL (bygningsarbejdet) og omvendt.



  1. Dvalebrug af PostgreSQL-sekvens påvirker ikke sekvenstabellen

  2. MYSQL:HVIS har OR-tilstand ®EXP-match

  3. Oracle INSERT INTO SELECT(...) DUP_VAL_ON_INDEX undtagelsesadfærd

  4. Forårsaget af:java.sql.SQLEundtagelse:Adgang nægtet for brugeren 'root'@'localhost' (ved hjælp af adgangskode:JA)