Ik zag mijn senior ontwikkelaars WITH (NOLOCK) gebruiken bij het queryen in SQL Server en vraag me af waarom ze dat gebruiken. Nu heb ik het onderzocht en ontdekt dat het nuttig is om de prestaties bij het uitvoeren van de query te verbeteren. Er is echter een nadeel aan het gebruik ervan. Het nadeel is dat men niet zeker weet of men de data krijgt die momenteel in de tabel wordt bijgewerkt, oftewel, zonder vergrendelingsbeveiliging kun je niet garanderen dat de data niet dat wel wordt gedaan veranderen tijdens de tijd dat de query draait. Ik heb deze link verwezen en vond hem erg nuttig.
Om de prestaties van SQL-querys te verbeteren, is het in het algemeen de eerste overweging om een index aan te maken. Sterker nog, naast het opzetten van indexen, kan het toevoegen van een sectie WITH (NOLOCK) aan de syntaxis bij het plaatsen van datasets die worden LOCKED in een omgeving met een groot aantal online queries verbeteren, waardoor de queryprestaties verbeteren.
Eén ding om op te merken is echter dat SQL SELECT met (NOLOCK) een vuile read kan veroorzaken.
Bijvoorbeeld:
Omdat SQL Server de bijbehorende lock consistency-check uitvoert. Om de algehele prestaties van databasequerys te verbeteren, voeg WITH (NOLOCK) toe aan het einde van de tabelnaam in je SELECT-syntaxis, hoewel (NOLOCK) ook acceptabel is, maar Microsoft raadt nog steeds aan om WITH toe te voegen.
Naast eenvoudige SELECT kun je ook de SELECT-syntaxis gebruiken met JOIN. Maar DELETE, INSERT, UPDATE en andere commando's die transacties vereisen zijn niet goed...
Sommige bestanden zeggen dat de efficiëntie van SQL-querys met 33% kan worden verhoogd met WITH (NOLOCK).
Het toevoegen van WITH (NOLOCK) vertelt SQL Server dat ons SELECT-commando niet hoeft rekening te houden met de transaction lock-status van de huidige tabel, waardoor de prestaties aanzienlijk verbeteren en het lock-fenomeen van het databasesysteem aanzienlijk zal worden verminderd (inclusief deadlock).
Een ding om op te merken is dat omdat WITH (NOLOCK) geen rekening houdt met de transactievergrendeling van de huidige tabel, dus wanneer er data is in meerdere fasen van een transactie (bijvoorbeeld een transactie over meerdere tabellen - > zoals een opnamesysteem), WITH (NOLOCK) de data die momenteel het transactieproces verwerkt, negeert...
Om het maar bot te zeggen: bij het gebruik van NoLock kan men gegevens lezen die zijn aangepast maar de transactie nog niet is afgerond. Daarom moet je, als je rekening moet houden met de realtime integriteit van transactiegegevens, goed nadenken over het gebruik van WITH (NOLOCK).
Als je geen transacties hoeft te overwegen, kan WITH (NOLOCK) een nuttige referentie zijn.
Noot 1: MET ( < table_hint > )
Specificeert de tabelscan, een of meer indexen die door de query-optimizer worden gebruikt,
Of door de query-optimizer om deze datatabel te benutten en de lock mode voor deze instructie te gebruiken.
Noot 2: WITH (NOLOCK) is gelijkwaardig aan READ UNCOMMITTED
Laten we tot slot een paar kleine verschillen bespreken tussen nolock en with(nolock):
1: Synoniemen in SQL05, alleen met (nolock) worden ondersteund;
2: met (nolock) wordt heel eenvoudig geschreven en vervolgens de index gespecificeerd.
Bij het queryen van statements over servers heen, kun je niet gebruiken met (nolock), alleen nolock
Bij het queryen op dezelfde server kunnen zowel met (nolock) als nolock worden gebruikt
Wat dan?
SQL-code
selecteer * uit [IP].a.dbo.table1 met (nolock) Dit geeft je de foutmelding select * uit a.dbo.table1 met (nolock) Dit werkt |
Geplaatst op 08-01-2016 17:58:31
|
|
|
