Vergrendelgranulariteit in MySQL begrijpen

Als je al een tijdje met MySQL werkt, heb je waarschijnlijk wel eens gehoord van de termen 'vergrendeling op tafelniveau' en 'vergrendeling op rijniveau'. Deze termen verwijzen naar de slotgranulariteit in MySQL - in deze blog leggen we uit wat ze betekenen en waarvoor ze kunnen worden gebruikt.

Wat is Lock-granulariteit in MySQL?

Elke MySQL-opslagengine ondersteunt verschillende granulariteitsniveaus voor hun vergrendelingen. MySQL heeft drie vergrendelingsniveaus:vergrendeling op rijniveau, vergrendeling op paginaniveau en vergrendeling op tafelniveau. Elke MySQL-opslagengine implementeert vergrendeling op een andere manier, waardoor u een aantal duidelijke voor- en nadelen krijgt. We zullen eerst kijken naar de granulariteit van het slot en vervolgens kijken hoe alles werkt in verschillende opslagengines.

Over het algemeen vallen sloten in MySQL in een van deze categorieën. Sloten kunnen zijn:

• Paginaniveau - dergelijke typen vergrendelingsgranulariteiten waren beschikbaar in oudere engines van MySQL, met name BDB, wat nu verouderd vanaf MySQL 5.1. Kortom, BDB was een opslagengine die was opgenomen in de oudere versies van MySQL en het was een transactionele opslagengine die vergrendelingen op paginaniveau uitvoerde. Aangezien dit soort vergrendelingsgranulariteiten niet langer worden gebruikt, zullen we hier niet dieper op ingaan, maar in het algemeen zijn deze vergrendelingen beperkt tot de gegevens en indexen die zich op een bepaalde pagina bevinden. Als je meer wilt weten over BDB, zou de pagina op MariaDB wat meer informatie moeten geven.

• Tabelniveau - MySQL gebruikt vergrendeling op tabelniveau voor alle opslagengines behalve InnoDB.

• Rijniveau - vergrendeling op rijniveau wordt gebruikt door InnoDB.

De voor- en nadelen van vergrendeling op tabelniveau

MySQL gebruikt vergrendeling op tabelniveau voor alle opslag-engines behalve InnoDB, wat betekent dat vergrendeling op tabelniveau wordt gebruikt voor tabellen met de opslag-engines MyISAM, MEMORY en MERGE, waardoor slechts één sessie tabellen tegelijk kan bijwerken . Vergrendelingen op tabelniveau hebben een aantal duidelijke voordelen ten opzichte van vergrendelingen op rijniveau (vergrendeling op tabelniveau vereist in het algemeen iets minder geheugen dan vergrendeling op rijniveau, omdat vergrendeling op rijniveau enig geheugen vereist per rij (of groep) van de rijen die zijn vergrendeld en het is meestal snel omdat er maar één slot bij betrokken is. Tafelschrijfsloten worden op een tafel geplaatst als er geen sloten op zijn - als er reeds bestaande sloten op de tafel in kwestie zijn, worden de tafelvergrendelingsverzoeken geplaatst Het is de moeite waard om te vermelden dat vergrendeling op tabelniveau ook enkele duidelijke nadelen heeft die uniek zijn voor zichzelf - het is bijvoorbeeld misschien niet erg geschikt voor toepassingen die veel transacties vereisen die "heen en weer" gaan (bijv. , een toepassing voor online bankieren) omdat slechts één sessie tegelijkertijd naar een tafel kan schrijven en sommige tabellen die vergrendeling op tafelniveau ondersteunen (zoals MyISAM) het ACID-model niet ondersteunen.

Hier is een voorbeeld:stel je een banktoepassing voor die twee tabellen in een database gebruikt - laten we zeggen dat die tabellen "controleren" en "sparen" worden genoemd. U moet $ 100 van iemands betaalrekening naar zijn spaarrekening verplaatsen. Logischerwijs zou u de volgende stappen uitvoeren:

1. Zorg ervoor dat het accountsaldo hoger is dan $ 100.

2. Trek $100 af van de betaalrekening.

3. Voeg $100 toe aan de spaarrekening.

Om deze acties uit te voeren, heeft u een aantal zoekopdrachten nodig, bijvoorbeeld:

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;

Deze zoekopdrachten zien er misschien eenvoudig uit, maar als u MyISAM gebruikt (we gebruiken MyISAM als voorbeeld omdat het een van de primaire opslagengines is die vergrendelingen op tabelniveau ondersteunt), moet u bekend zijn met het feit dat de engine ondersteunt ook geen ACID, wat betekent dat als de databaseserver crasht tijdens het uitvoeren van een van die zoekopdrachten, je pech hebt:mensen kunnen eindigen met contant geld op beide accounts of in geen van beide. De enige engine die ACID-gebaseerde transacties in MySQL ondersteunt, is InnoDB, dus als je veel betrouwbare transacties nodig hebt, is het misschien de moeite waard om ernaar te kijken. InnoDB ondersteunt ook vergrendeling op rijniveau - dit is waar we nu naar gaan kijken.

De voor- en nadelen van vergrendeling op rijniveau

MySQL gebruikt vergrendeling op rijniveau voor InnoDB-tabellen om gelijktijdige schrijftoegang door meerdere sessies te ondersteunen. Enkele van de voordelen van het gebruik van vergrendeling op rijniveau zijn de mogelijkheid om een ​​enkele rij gedurende lange tijd te vergrendelen en minder vergrendelingsconflicten wanneer veel threads toegang hebben tot verschillende rijen. Vergrendeling op rijniveau heeft echter ook nadelen:een daarvan is dat vergrendeling op rijniveau meestal meer geheugen in beslag neemt dan vergrendeling op pagina- of tabelniveau, het is ook meestal langzamer dan vergrendeling op pagina- of tabelniveau omdat de engine meer sloten moeten aanschaffen. InnoDB is een van de motoren die een vergrendelingsmechanisme op rijniveau ondersteunt:het is ook ACID-compatibel, wat betekent dat het goed geschikt is voor op transacties gebaseerde toepassingen (zie het bovenstaande voorbeeld). Nu gaan we kijken hoe de granulariteit van het slot werkt in een van de MySQL-opslagengines.

Hoe werkt Lock Granularity in InnoDB?

Het is algemeen bekend dat InnoDB vergrendeling op rijniveau ondersteunt, maar het is ook vermeldenswaard dat de engine meerdere soorten vergrendeling ondersteunt, wat betekent dat u zowel vergrendelingen op rijniveau als op tabelniveau kunt gebruiken. InnoDB voert vergrendeling op rijniveau uit door gedeelde of exclusieve vergrendelingen in te stellen op de indexrecords die het tegenkomt wanneer het een tabelindex zoekt of scant. Een gedeelde vergrendeling is zo'n vergrendeling waarmee de transactie die de vergrendeling vasthoudt, de rij in kwestie kan lezen, terwijl een exclusieve vergrendeling de transactie met de vergrendeling toelaat om een ​​rij bij te werken of te verwijderen.

InnoDB heeft ook andere soorten vergrendelingen - sommige bevatten gedeelde en exclusieve vergrendelingen, intentievergrendelingen, recordvergrendelingen, gap-vergrendelingen, next-key-vergrendelingen en next-intentievergrendelingen. Intentievergrendelingen kunnen bijvoorbeeld ook gedeeld of exclusief zijn - dergelijke vergrendelingen geven meestal aan dat een transactie bedoeld is om een ​​bepaald type slot (een gedeeld slot of een exclusief slot) op afzonderlijke rijen in een tabel in te stellen, een recordslot is een een indexrecord enz. vergrendelen.

Over het algemeen verschilt de granulariteit van de InnoDB-vergrendeling van de granulariteit van de vergrendeling die aanwezig is in andere MySQL-opslagengines (bijvoorbeeld MyISAM), omdat wanneer vergrendeling op tabelniveau wordt gebruikt, er slechts één sessie is om bepaalde tabellen tegelijk bij te werken. tijd kan lopen. Wanneer vergrendeling op rijniveau wordt gebruikt, ondersteunt MySQL gelijktijdige schrijftoegang voor meerdere sessies, waardoor opslagengines voor vergrendeling op rijniveau (InnoDB) een geschikte keuze zijn voor bedrijfskritieke toepassingen.

granulariteit en impasses vergrendelen

Vergrendelingsgranulariteit en vergrendelingsniveaus in MySQL kunnen geweldig zijn, maar ze kunnen ook problemen veroorzaken. Een van de meest voorkomende problemen die worden veroorzaakt door granulariteit van vergrendelingen zijn deadlocks - een deadlock treedt op wanneer verschillende MySQL-transacties niet kunnen doorgaan omdat elk van hen een slot bevat dat de ander nodig heeft. Gelukkig is deadlock-detectie bij gebruik van de InnoDB-opslagengine standaard ingeschakeld - wanneer een deadlock wordt gedetecteerd, draait InnoDB automatisch een transactie terug. Als u impasses tegenkomt bij het omgaan met granulariteit van slots in MySQL, hoeft u zich geen zorgen te maken - overweeg om uw transactie gewoon opnieuw te starten. Om uw database proactief te bewaken, moet u ook overwegen om de functies van ClusterControl te gebruiken.

Hoe kan ClusterControl u helpen?

Hier zijn enkele zaken waarmee ClusterControl, ontwikkeld door Verscheidenenines, u kan helpen:

• De bescherming van al uw bedrijfsgegevens

  • Als uw gegevens beschadigd zijn (dat kan worden veroorzaakt door het niet gebruiken van een ACID-compatibele opslagengine of door andere factoren zoals hierboven beschreven) kan de tool een automatisch proces uitvoeren dat daadwerkelijk verifieert dat u uw gegevens kunt herstellen.

  • De tool kan u laten weten van welke databases geen back-up is gemaakt of u de status van uw back-ups laten zien (of ze waren succesvol of ze faalden)

• De automatisering van uw databasebewerkingen

  • ClusterControl kan u helpen ervoor te zorgen dat uw systeembeheerders, ontwikkelaars en DBA's volledige databaseclusters efficiënt beheren met minimale risico's met behulp van de industrie best practices

• Effectief beheer van uw database-infrastructuur in het algemeen

  • De huidige verschuiving in technologieën in combinatie met geavanceerde infrastructuuroplossingen vereist geavanceerde tools en kennis om hoge beschikbaarheid en optimale prestaties voor uw bedrijfskritische applicaties. ClusterControl kan u ook helpen met de implementatie, monitoring, beheer en schaling van de meest populaire open source databasetechnologieën, waaronder MySQL, MariaDB, MongoDB, PostgreSQL, TimeScaleDB en de rest.

Als u meer wilt weten over hoe ClusterControl u kan helpen bij het stroomlijnen van uw bedrijfsvoering, houdt u dan zeker de databaseblog van de verschillendenines in de gaten.

Samenvatting

Verschillende MySQL-opslagengines hebben verschillende typen vergrendelingsgranulariteiten beschikbaar. Voordat u beslist welke storage-engine u moet gebruiken, moet u ervoor zorgen dat u zoveel mogelijk informatie over de storage-engine in kwestie weet (zoals bijvoorbeeld al is opgemerkt, moet MyISAM worden vermeden bij het omgaan met bedrijfskritieke gegevens omdat deze niet ACID-compatibel is), begrijp alle gerelateerde prestatie-implicaties, inclusief slotgranulariteiten, impasses en de rest, en kies verstandig.