Hvis du har arbejdet med MySQL i nogen tid, har du sikkert hørt udtrykkene "table-level locking" og "row-level locking". Disse termer refererer til låsegranulariteten i MySQL - i denne blog vil vi forklare, hvad de betyder, og hvad de kan bruges til.
Hvad er Lock Granularity i MySQL?
Hver MySQL-lagringsmotor understøtter forskellige niveauer af granularitet for deres låse. MySQL har tre låseniveauer:rækkeniveaulåsning, sideniveaulåsning og tabelniveaulåsning. Hver MySQL-lagringsmotor implementerer låsning forskelligt, hvilket giver dig nogle distinkte fordele og ulemper. Vi vil først se nærmere på, hvad låsegranularitet er, og derefter undersøge, hvordan alt fungerer i forskellige lagringsmotorer.
I store træk falder låse i MySQL ind under en af disse kategorier. Låse kan være:
-
Sideniveau - sådanne typer låsegranulariteter var tilgængelige i ældre MySQL-motorer, specifikt BDB, som er nu forældet fra MySQL 5.1. Kort sagt var BDB en lagringsmotor inkluderet i de ældre versioner af MySQL, og det var en transaktionslagringsmotor, som udførte låse på sideniveau. Da disse typer af låsegranulariteter ikke længere bruges, vil vi ikke gå i dybden med dem her, men generelt er disse låse begrænset til de data og indekser, der findes på en bestemt side. Hvis du vil lære mere om BDB, bør siden på MariaDB give nogle flere oplysninger.
-
Tabelniveau - MySQL bruger tabelniveaulåsning til alle lagermaskiner undtagen InnoDB.
-
Rækkeniveau - rækkeniveaulåsning bruges af InnoDB.
Fordele og ulemper ved låsning på bordniveau
MySQL bruger tabelniveaulåsning til alle lagermotorer undtagen InnoDB, hvilket betyder, at tabelniveaulåsning bruges til tabeller, der kører MyISAM-, MEMORY- og MERGE-lagringsmotorerne, hvilket kun tillader én session at opdatere tabeller ad gangen . Låse på bordniveau har nogle tydelige fordele i forhold til låse på rækkeniveau (for eksempel kræver låsning på bordniveau generelt lidt mindre hukommelse end låsning på rækkeniveau, fordi låsning på rækkeniveau kræver noget hukommelse pr. række (eller gruppe) af rækkerne der er låst, og det er normalt hurtigt, fordi der kun er én lås involveret. Bordskrivelåse sættes på et bord, hvis der ikke er låse på det - hvis der allerede er låse på det pågældende bord, sættes bordlåsanmodningerne ind. læseanmodningskøen. Det er værd at nævne, at låsning på bordniveau også har nogle særskilte ulemper, der er unikke for sig selv - for eksempel passer det måske ikke særlig godt til applikationer, der kræver mange transaktioner, der går "frem og tilbage" (f.eks. , en netbankapplikation), fordi kun én session kan skrive til en tabel ad gangen, og nogle af de tabeller, der understøtter låsning på tabelniveau (såsom MyISAM), understøtter ikke ACID-modellen.
Her er et eksempel:forestil dig en bankapplikation, der bruger to tabeller i en database - lad os sige, at disse tabeller kaldes "kontrol" og "opsparing". Du skal flytte $100 fra en persons checkkonto til hans opsparingskonto. Logisk set ville du udføre følgende trin:
-
Sørg for, at kontosaldoen er større end 100 USD.
-
Træk 100 USD fra checkkontoen.
-
Føj $100 til opsparingskontoen.
For at udføre disse handlinger skal du have et par forespørgsler, for eksempel:
SELECT balance FROM checking WHERE account_id = 123;
UPDATE checking SET balance = balance - 100 WHERE account_id = 123;
UPDATE savings SET balance = balance + 100 WHERE account_id = 123;Disse forespørgsler ser måske enkle ud, men hvis du bruger MyISAM (vi bruger MyISAM som eksempel, da det er en af de primære lagermotorer, der understøtter låse på tabelniveau), bør du være bekendt med, at motoren understøtter heller ikke ACID, hvilket betyder, at hvis databaseserveren går ned, mens du udfører nogen af disse forespørgsler, er du uheldig:folk kan ende med kontanter på begge konti eller på ingen af dem. Den eneste motor, der understøtter ACID-baserede transaktioner i MySQL, er InnoDB, så hvis du har brug for en masse pålidelige transaktioner, kan det være værd at undersøge det. InnoDB understøtter også række-niveau-låsning - det er det, vi vil se nærmere på nu.
Fordele og ulemper ved låsning på rækkeniveau
MySQL bruger rækkeniveaulåsning til InnoDB-tabeller for at understøtte samtidig skriveadgang ved flere sessioner. Nogle af fordelene ved at bruge låsning på rækkeniveau inkluderer muligheden for at låse en enkelt række i lange perioder og færre låsekonflikter, når mange tråde får adgang til forskellige rækker. Låsning på rækkeniveau har dog også ulemper:en af dem er, at låsning på rækkeniveau normalt optager mere hukommelse end låsning på sideniveau eller tabelniveau, den er også normalt langsommere end låsning på sideniveau eller tabelniveau, fordi motoren skal anskaffe flere låse. InnoDB er en af de motorer, der understøtter en låsemekanisme på rækkeniveau:den er også ACID-kompatibel, hvilket betyder, at den passer godt til transaktionsbaserede applikationer (se eksemplet ovenfor). Nu vil vi se på, hvordan låsegranularitet fungerer i en af MySQL-lagringsmotorerne.
Hvordan virker Lock Granularity i InnoDB?
InnoDB er almindeligt kendt for at understøtte række-niveau-låsning, men det er også værd at bemærke, at motoren understøtter flere typer låsning, hvilket betyder, at du kan bruge både række-niveau og bord-niveau låse. InnoDB udfører låsning på rækkeniveau ved at indstille delte eller eksklusive låse på de indeksposter, den støder på, når den søger eller scanner et tabelindeks. En delt lås er en sådan lås, der tillader transaktionen, der holder låsen, at læse den pågældende række, en eksklusiv lås tillader på den anden side den transaktion, der holder låsen, at opdatere eller slette en række.
InnoDB har også andre typer låse - nogle af dem inkluderer delte og eksklusive låse, intentionslåse, rekordlåse, spaltelåse, næste-tastelåse og næste intentionslåse. Intentionslåse kan for eksempel også være delte eller eksklusive - sådanne låse indikerer normalt, at en transaktion har til hensigt at sætte en bestemt type lås (en delt lås eller en eksklusiv lås) på individuelle rækker i en tabel, en rekordlås er en lås på en indekspost osv.
Generelt adskiller InnoDB-låsegranulariteten sig fra den låsegranularitet, der findes i andre MySQL-lagringsmotorer (f.eks. MyISAM), fordi når låsning på tabelniveau er i brug, er der kun én session til at opdatere visse tabeller på en tiden kan løbe. Når række-niveau-låsning er i brug, understøtter MySQL samtidig skriveadgang på tværs af flere sessioner, hvilket gør række-niveau låse-lagringsmotorer (InnoDB) til et passende valg til missionskritiske applikationer.
Lås granularitet og deadlocks
Lås granularitet og låseniveauer i MySQL kan være en stor ting, men de kan også forårsage problemer. Et af de hyppigste problemer forårsaget af låsegranularitet er deadlocks - en deadlock opstår, når forskellige MySQL-transaktioner ikke er i stand til at fortsætte, fordi hver af dem har en lås, som den anden har brug for. Heldigvis, når du bruger InnoDB-lagringsmotoren, er deadlock-detektion aktiveret som standard - når en deadlock opdages, ruller InnoDB automatisk en transaktion tilbage. Hvis du støder på deadlocks, når du håndterer låsegranularitet i MySQL, skal du ikke bekymre dig - overvej blot at genstarte din transaktion. For proaktivt at overvåge din database, bør du også overveje at bruge funktionerne fra ClusterControl.
Hvordan kan ClusterControl hjælpe dig?
Her er nogle af de ting, ClusterControl udviklet af Severalnines kan hjælpe dig med:
-
Beskyttelsen af alle dine virksomhedsdata
-
Hvis dine data er beskadiget (det kan være forårsaget af ikke at bruge en ACID-kompatibel lagermotor eller også af andre faktorer som beskrevet ovenfor) kan værktøjet køre en automatisk proces, der faktisk bekræfter, at du kan gendanne dine data.
-
Værktøjet kan fortælle dig, hvilke databaser der ikke er sikkerhedskopieret eller vise dig status for dine sikkerhedskopier (uanset om de lykkedes, eller de mislykkedes)
-
-
Automatiseringen af dine databaseoperationer
-
ClusterControl kan hjælpe dig med at sikre, at dine systemadministratorer, udviklere og DBA'er administrerer hele databaseklynger effektivt med minimale risici ved brug af industrien bedste praksis
-
-
Effektiv administration af din databaseinfrastruktur generelt
-
Dagens skift i teknologier kombineret med sofistikerede infrastrukturløsninger kræver avancerede værktøjer og viden for at opnå høj tilgængelighed og optimal ydeevne for dine forretningskritiske applikationer. ClusterControl kan også hjælpe dig med implementering, overvågning, styring og skalering af de mest populære open source-databaseteknologier, herunder MySQL, MariaDB, MongoDB, PostgreSQL, TimeScaleDB og resten.
-
For at lære mere om, hvordan ClusterControl kan hjælpe med at strømline din virksomhedsdrift, skal du sørge for at holde øje med Severalnines-databasebloggen.
Oversigt
Forskellige MySQL-lagringsmotorer har forskellige typer låsegranulariteter. Før du beslutter dig for, hvilken lagringsmotor du skal bruge, skal du sørge for at kende så mange oplysninger om den pågældende lagringsmotor som muligt (som f.eks. allerede nævnt bør MyISAM undgås, når du håndterer missionskritiske data, fordi det ikke er ACID-kompatibelt), forstå alle de relaterede præstationsimplikationer, herunder låsegranulariteter, deadlocks og resten, og vælg med omtanke.