Isolering
Svep för att visa menyn
I databassammanhang avser isolering en databashanterares förmåga att kontrollera synligheten av ändringar som görs av samtidiga transaktioner. Det säkerställer att transaktioner fungerar oberoende av varandra, undviker störningar och upprätthåller dataintegritet.
Det finns 4 isoleringsnivåer i SQL:
- read uncommitted;
- read committed;
- repeatable read;
- serializable.
Read uncommitted
Detta är den lägsta isoleringsnivån där transaktioner kan se ändringar som gjorts av andra transaktioner även innan de har bekräftats. Denna nivå tillåter smutsiga läsningar, vilket innebär att en transaktion kan läsa data som har ändrats av en annan transaktion men ännu inte bekräftats.
Smutsiga läsningar
En smutsig läsning uppstår när en transaktion läser data som har ändrats av en annan transaktion men ännu inte bekräftats.
Till exempel, tänk dig två banktransaktioner som sker samtidigt: Transaktion A kontrollerar ditt kontosaldo medan Transaktion B sätter in pengar på ditt konto. Om Transaktion A ser det ökade saldot innan Transaktion B är klar, är det en smutsig läsning, eftersom det nya saldot kan återställas om Transaktion B misslyckas.
Implementering
För att ange isolationsnivån för transaktionen kan vi använda följande kommando i vår fråga:
-- Start transaction
BEGIN;
-- Set the isolation level for the transaction
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
/* Transaction query */
COMMIT;
-
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;: Detta kommando ändrar isolationsnivån för den aktuella transaktionen till "Read Uncommitted", vilket tillåter transaktionen att potentiellt läsa data som har ändrats av andra icke-committade transaktioner; -
detta kommando måste användas endast inom transaktionsblocket! Annars har det ingen effekt och en standardisolationsnivå kommer att användas.
Vi kan också kontrollera aktuell isolationsnivå med följande kommando:
SHOW TRANSACTION ISOLATION LEVEL;
Read committed
Isolationsnivån Read Committed säkerställer att en transaktion endast ser data som har committats av andra transaktioner.
Detta innebär att icke-committade ändringar som gjorts av andra transaktioner inte är synliga för transaktioner som körs under Read Committed-isolering.
Som ett resultat förhindras smutsiga läsningar genom att en transaktion endast kan läsa committad data. Dock har denna transaktionsnivå problem med icke-repetitiva läsningar.
Icke-repetitiva läsningar
En icke-repetitiv läsning uppstår när en transaktion läser samma rad flera gånger inom samma transaktion, men den data som hämtas ändras mellan läsningarna på grund av ändringar som gjorts av andra transaktioner. Denna inkonsekvens kan leda till oväntat beteende och felaktiga resultat.
Till exempel, tänk dig en transaktion som frågar efter en kunds kontosaldo två gånger. Den första frågan returnerar 1000 $, men innan transaktionen är klar sätter en annan transaktion in 500 $ på kontot. När den andra frågan körs visas 1500 $, vilket leder till en icke-repetitiv läsning där samma data läses olika inom en enda transaktion på grund av ändringar som gjorts av en annan transaktion.
Isolationsnivån "Read committed" tillåter icke-repetitiva läsningar eftersom den låser läsoperationen på värden som är under pågående icke-committade transaktioner men låser inte skrivoperationen.
Som ett resultat kan vi skriva ny data till raden som för närvarande läses av en annan transaktion.
Förlorad uppdatering
På grund av avsaknaden av skrivlås finns det ytterligare ett problem med isoleringsnivån read committed – förlorade uppdateringar.
En förlorad uppdatering är en situation inom databashantering där en transaktion skriver över ändringar som gjorts av en annan transaktion, vilket leder till att data går förlorad. Detta inträffar vanligtvis när flera transaktioner försöker uppdatera samma data samtidigt, och en transaktions ändringar skrivs över av en annan transaktion innan de har bekräftats i databasen.
Förlorade uppdateringar uppstår när två parallella transaktioner försöker ändra samma rad. Som ett resultat skriver den transaktion som bekräftas sist över de värden som bekräftats av andra transaktioner.
Implementation
Vi kan också ange denna isoleringsnivå med följande kommandon:
-- Start transaction
BEGIN;
-- Set the isolation level for the session
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
/* Transaction query */
COMMIT;
Det är viktigt att notera att Read Committed är standardisolationsnivån för de flesta databashanteringssystem, vilket gör att vi kan utelämna att specificera den.
Tack för dina kommentarer!
Fråga AI
Fråga AI
Fråga vad du vill eller prova någon av de föreslagna frågorna för att starta vårt samtal
Isolering
I databassammanhang avser isolering en databashanterares förmåga att kontrollera synligheten av ändringar som görs av samtidiga transaktioner. Det säkerställer att transaktioner fungerar oberoende av varandra, undviker störningar och upprätthåller dataintegritet.
Det finns 4 isoleringsnivåer i SQL:
- read uncommitted;
- read committed;
- repeatable read;
- serializable.
Read uncommitted
Detta är den lägsta isoleringsnivån där transaktioner kan se ändringar som gjorts av andra transaktioner även innan de har bekräftats. Denna nivå tillåter smutsiga läsningar, vilket innebär att en transaktion kan läsa data som har ändrats av en annan transaktion men ännu inte bekräftats.
Smutsiga läsningar
En smutsig läsning uppstår när en transaktion läser data som har ändrats av en annan transaktion men ännu inte bekräftats.
Till exempel, tänk dig två banktransaktioner som sker samtidigt: Transaktion A kontrollerar ditt kontosaldo medan Transaktion B sätter in pengar på ditt konto. Om Transaktion A ser det ökade saldot innan Transaktion B är klar, är det en smutsig läsning, eftersom det nya saldot kan återställas om Transaktion B misslyckas.
Implementering
För att ange isolationsnivån för transaktionen kan vi använda följande kommando i vår fråga:
-- Start transaction
BEGIN;
-- Set the isolation level for the transaction
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
/* Transaction query */
COMMIT;
-
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;: Detta kommando ändrar isolationsnivån för den aktuella transaktionen till "Read Uncommitted", vilket tillåter transaktionen att potentiellt läsa data som har ändrats av andra icke-committade transaktioner; -
detta kommando måste användas endast inom transaktionsblocket! Annars har det ingen effekt och en standardisolationsnivå kommer att användas.
Vi kan också kontrollera aktuell isolationsnivå med följande kommando:
SHOW TRANSACTION ISOLATION LEVEL;
Read committed
Isolationsnivån Read Committed säkerställer att en transaktion endast ser data som har committats av andra transaktioner.
Detta innebär att icke-committade ändringar som gjorts av andra transaktioner inte är synliga för transaktioner som körs under Read Committed-isolering.
Som ett resultat förhindras smutsiga läsningar genom att en transaktion endast kan läsa committad data. Dock har denna transaktionsnivå problem med icke-repetitiva läsningar.
Icke-repetitiva läsningar
En icke-repetitiv läsning uppstår när en transaktion läser samma rad flera gånger inom samma transaktion, men den data som hämtas ändras mellan läsningarna på grund av ändringar som gjorts av andra transaktioner. Denna inkonsekvens kan leda till oväntat beteende och felaktiga resultat.
Till exempel, tänk dig en transaktion som frågar efter en kunds kontosaldo två gånger. Den första frågan returnerar 1000 $, men innan transaktionen är klar sätter en annan transaktion in 500 $ på kontot. När den andra frågan körs visas 1500 $, vilket leder till en icke-repetitiv läsning där samma data läses olika inom en enda transaktion på grund av ändringar som gjorts av en annan transaktion.
Isolationsnivån "Read committed" tillåter icke-repetitiva läsningar eftersom den låser läsoperationen på värden som är under pågående icke-committade transaktioner men låser inte skrivoperationen.
Som ett resultat kan vi skriva ny data till raden som för närvarande läses av en annan transaktion.
Förlorad uppdatering
På grund av avsaknaden av skrivlås finns det ytterligare ett problem med isoleringsnivån read committed – förlorade uppdateringar.
En förlorad uppdatering är en situation inom databashantering där en transaktion skriver över ändringar som gjorts av en annan transaktion, vilket leder till att data går förlorad. Detta inträffar vanligtvis när flera transaktioner försöker uppdatera samma data samtidigt, och en transaktions ändringar skrivs över av en annan transaktion innan de har bekräftats i databasen.
Förlorade uppdateringar uppstår när två parallella transaktioner försöker ändra samma rad. Som ett resultat skriver den transaktion som bekräftas sist över de värden som bekräftats av andra transaktioner.
Implementation
Vi kan också ange denna isoleringsnivå med följande kommandon:
-- Start transaction
BEGIN;
-- Set the isolation level for the session
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
/* Transaction query */
COMMIT;
Det är viktigt att notera att Read Committed är standardisolationsnivån för de flesta databashanteringssystem, vilket gör att vi kan utelämna att specificera den.
Tack för dina kommentarer!
