Waarom een ​​LEES UNCOMMITTED isolatieniveau gebruiken?

Dit isolatieniveau maakt vuile uitlezingen mogelijk. Bij een transactie kunnen niet-vastgelegde wijzigingen worden aangebracht door een andere transactie.

Om het hoogste niveau van isolatie te behouden, verwerft een DBMS gewoonlijk vergrendelingen op gegevens, wat kan resulteren in een verlies van gelijktijdigheid en een hoge vergrendelingsoverhead. Dit isolatieniveau ontspant deze eigenschap.

Misschien wil je het Wikipedia-artikel lezen over READ UNCOMMITTED voor een paar voorbeelden en verder lezen.

Misschien ben je ook geïnteresseerd in het blogartikel van Jeff Atwood over hoe hij en zijn team een ​​impasse hebben aangepakt in de begindagen van Stack Overflow. Volgens Jeff:

Maar is nolock gevaarlijk? Kan het zijn dat u ongeldige gegevens leest met read uncommitted Aan? Ja, in theorie. Je zult geen tekort vinden aan databasearchitecture-astronauten die ACID-wetenschap op je beginnen te droppen en bijna het brandalarm van het gebouw trekken als je ze vertelt dat je nolock wilt proberen .Het is waar:de theorie is eng. Maar dit is wat ik denk:"In theorie is er geen verschil tussen theorie en praktijk. In de praktijk wel."

Ik zou het gebruik van nolock nooit aanraden als een algemene "goed voor wat je scheelt" slangenolie-oplossing voor eventuele database-deadlocking-problemen die je hebt. U moet eerst proberen de oorzaak van het probleem vast te stellen.

Maar in de praktijk toevoegen van nolock op vragen waarvan je absoluut weet dat het simpele, duidelijke alleen-lezen zaken zijn, lijkt nooit tot problemen te leiden... Zolang je weet wat je doet.

Een alternatief voor de READ UNCOMMITTED niveau dat u misschien wilt overwegen, is de READ COMMITTED SNAPSHOT . Ik citeer Jeff opnieuw:

Snapshots zijn gebaseerd op een geheel nieuwe methode voor het bijhouden van gegevenswijzigingen ... meer dan alleen een kleine logische verandering, het vereist dat de server de gegevens fysiek anders behandelt. Zodra deze nieuwe methode voor het bijhouden van gegevenswijzigingen is ingeschakeld, wordt een kopie of momentopname gemaakt van elke gegevenswijziging. Door deze snapshots te lezen in plaats van live gegevens in tijden van onenigheid, zijn gedeelde vergrendelingen niet langer nodig bij het lezen en kunnen de algehele databaseprestaties toenemen.