Förstå låsgranularitet i MySQL

Om du har arbetat med MySQL ett tag har du förmodligen hört termerna "bordsnivålåsning" och "radnivålåsning". Dessa termer hänvisar till låsgranulariteten i MySQL - i den här bloggen kommer vi att förklara vad de betyder och vad de kan användas till.

Vad är Lock Granularity i MySQL?

Varje MySQL-lagringsmotor stöder olika nivåer av granularitet för sina lås. MySQL har tre låsnivåer:låsning på radnivå, låsning på sidnivå och låsning på tabellnivå. Varje MySQL-lagringsmotor implementerar låsning på olika sätt, vilket ger dig några distinkta fördelar och nackdelar. Vi ska först undersöka vad låsgranularitet är och sedan undersöka hur allt fungerar i olika lagringsmotorer.

I stort sett faller lås i MySQL in i en av dessa kategorier. Lås kan vara:

• Sidnivå - sådana typer av låsgranulariteter var tillgängliga i äldre MySQL-motorer, särskilt BDB, vilket är nu föråldrad från och med MySQL 5.1. Kort sagt, BDB var en lagringsmotor som ingick i de äldre versionerna av MySQL och det var en transaktionslagringsmotor som utförde sidnivålås. Eftersom dessa typer av låsgranulariteter inte längre används kommer vi inte att gå in på dem här, men i allmänhet är dessa lås begränsade till data och index som finns på en viss sida. Om du vill lära dig mer om BDB bör sidan på MariaDB ge lite mer information.

• Tabellnivå - MySQL använder tabellnivålåsning för alla lagringsmotorer utom InnoDB.

• Radnivå - radnivålåsning används av InnoDB.

Fördelar och nackdelar med låsning på bordsnivå

MySQL använder tabellnivålåsning för alla lagringsmotorer utom InnoDB vilket betyder att tabellnivålåsning används för tabeller som kör lagringsmotorerna MyISAM, MEMORY och MERGE, vilket tillåter endast en session att uppdatera tabeller åt gången . Lås på tabellnivå har några distinkta fördelar jämfört med lås på radnivå (till exempel kräver tabelllåsning i allmänhet lite mindre minne än låsning på radnivå eftersom låsning på radnivå kräver lite minne per rad (eller grupp) av raderna som är låsta och det brukar gå snabbt eftersom det bara är ett lås inblandat. Bordsskrivlås sätts på ett bord om det inte finns några lås på det - om det finns redan befintliga lås på bordet i fråga läggs begäran om bordslås in läsbegäran. Det är värt att nämna att låsning på tabellnivå har några distinkta nackdelar som är unika för sig själv också - till exempel kanske det inte passar särskilt bra för applikationer som kräver många transaktioner som går "fram och tillbaka" (t.ex. , en onlinebankapplikation) eftersom endast en session kan skriva till en tabell åt gången och några av tabellerna som stöder låsning på tabellnivå (som MyISAM) stöder inte ACID-modellen.

Här är ett exempel:tänk dig en bankapplikation som använder två tabeller i en databas - låt oss säga att dessa tabeller kallas "kontroll" och "besparingar". Du måste flytta $100 från en persons checkkonto till hans sparkonto. Logiskt sett skulle du utföra följande steg:

1. Se till att kontosaldot är större än 100 USD.

2. Ta bort 100 USD från checkkontot.

3. Lägg till 100 USD på sparkontot.

För att utföra dessa åtgärder skulle du behöva ett par frågor, till exempel:

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;

De här frågorna kan se enkla ut, men om du använder MyISAM (vi använder MyISAM som exempel eftersom det är en av de primära lagringsmotorerna som stöder lås på tabellnivå), bör du vara bekant med det faktum att motorn stöder inte ACID heller, vilket betyder att om databasservern kraschar när du utför någon av dessa frågor, har du ingen tur:folk kan få pengar på båda kontona eller på inget av dem. Den enda motorn som stöder ACID-baserade transaktioner i MySQL är InnoDB, så om du behöver många pålitliga transaktioner kan det vara värt att titta närmare på det. InnoDB stöder också låsning på radnivå - det här är vad vi ska titta på nu.

Fördelar och nackdelar med låsning på radnivå

MySQL använder radnivålåsning för InnoDB-tabeller för att stödja samtidig skrivåtkomst av flera sessioner. Några av fördelarna med att använda låsning på radnivå inkluderar möjligheten att låsa en enskild rad under långa tidsperioder och färre låskonflikter när många trådar kommer åt olika rader. Men låsning på radnivå har också nackdelar:en av dem är att låsning på radnivå vanligtvis tar upp mer minne än låsning på sidnivå eller tabellnivå, det är också vanligtvis långsammare än låsning på sidnivå eller tabellnivå eftersom motorn måste skaffa fler lås. InnoDB är en av motorerna som stöder en låsmekanism på radnivå:den är också ACID-kompatibel, vilket innebär att den passar bra för transaktionsbaserade applikationer (se exemplet ovan). Nu ska vi undersöka hur låsgranularitet fungerar i en av MySQL-lagringsmotorerna.

Hur fungerar låsgranularitet i InnoDB?

InnoDB är allmänt känt för att stödja radnivålåsning, men det är också värt att notera att motorn stöder flera typer av låsning vilket innebär att du kan använda både radnivå- och bordsnivålås. InnoDB utför låsning på radnivå genom att ställa in delade eller exklusiva lås på indexposterna den stöter på när den söker eller skannar ett tabellindex. Ett delat lås är ett sådant lås som tillåter transaktionen som håller låset att läsa raden i fråga, ett exklusivt lås å andra sidan tillåter transaktionen som håller låset att uppdatera eller ta bort en rad.

InnoDB har även andra typer av lås - några av dem inkluderar delade och exklusiva lås, avsiktslås, skivlås, gaplås, nästa-nyckellås och nästa avsiktslås. Intentionslås kan till exempel också vara delade eller exklusiva - sådana lås indikerar vanligtvis att en transaktion avser att sätta en viss typ av lås (ett delat lås eller ett exklusivt lås) på enskilda rader i en tabell, ett postlås är ett låsa på en indexpost etc.

I allmänhet skiljer sig InnoDB-låsgranulariteten från låsgranulariteten som finns i andra MySQL-lagringsmotorer (till exempel MyISAM) eftersom när låsning på tabellnivå används, bara en session för att uppdatera vissa tabeller vid en tiden kan springa. När radnivålåsning används, stöder MySQL samtidig skrivåtkomst över flera sessioner, vilket gör radnivålåsningslagringsmotorer (InnoDB) till ett lämpligt val för verksamhetskritiska applikationer.

Lås granularitet och dödlägen

Lås granularitet och låsningsnivåer i MySQL kan vara bra, men de kan också orsaka problem. Ett av de vanligaste problemen som orsakas av låsgranularitet är dödlägen - ett dödläge uppstår när olika MySQL-transaktioner inte kan fortsätta eftersom var och en av dem har ett lås som den andra behöver. Tack och lov, när du använder InnoDB-lagringsmotorn, är dödlägesdetektering aktiverad som standard - när ett dödläge upptäcks, återställer InnoDB automatiskt en transaktion. Om du stöter på låsningar när du hanterar låsgranularitet i MySQL, oroa dig inte - överväg att helt enkelt starta om din transaktion. För att proaktivt övervaka din databas bör du också överväga att använda funktionerna som tillhandahålls av ClusterControl.

Hur kan ClusterControl hjälpa dig?

Här är några av de saker som ClusterControl utvecklat av Severalnines kan hjälpa dig med:

• Skydd av alla dina affärsdata

  • Om din data är skadad (det kan bero på att du inte använder en ACID-kompatibel lagringsmotor eller också av andra faktorer som beskrivs ovan) kan verktyget köra en automatisk process som faktiskt verifierar att du kan återställa dina data.

  • Verktyget kan låta dig veta vilka databaser som inte säkerhetskopieras eller visa dig statusen för dina säkerhetskopior (oavsett om de var framgångsrika eller så misslyckades)

• Automatiseringen av dina databasoperationer

  • ClusterControl kan hjälpa dig att säkerställa att dina systemadministratörer, utvecklare och DBA:er hanterar hela databaskluster effektivt med minimala risker genom att använda industrin bästa praxis

• Hantera din databasinfrastruktur i allmänhet effektivt

  • Dagens teknikskifte kombinerat med sofistikerade infrastrukturlösningar kräver avancerade verktyg och kunskap för att uppnå hög tillgänglighet och optimal prestanda för dina affärskritiska applikationer. ClusterControl kan också hjälpa dig med distribution, övervakning, hantering och skalning av de mest populära databasteknologierna med öppen källkod, inklusive MySQL, MariaDB, MongoDB, PostgreSQL, TimeScaleDB och resten.

För att lära dig mer om hur ClusterControl kan hjälpa till att effektivisera din verksamhet, se till att hålla ett öga på Severalnines databasblogg.

Sammanfattning

Olika MySQL-lagringsmotorer har olika typer av låsgranulariteter tillgängliga. Innan du bestämmer dig för vilken lagringsmotor du ska använda, se till att känna till så mycket information om lagringsmotorn i fråga som möjligt (till exempel som redan nämnt bör MyISAM undvikas när du hanterar verksamhetskritiska data eftersom den inte är ACID-kompatibel), förstå alla relaterade prestandaimplikationer inklusive låsgranulariteter, dödlägen och resten och välj klokt.