Utilizzando con (NOLock) per aumentare le prestazioni

Question

Ho visto gli sviluppatori usare con (NOLock) nella query, c'è uno svantaggio? Inoltre, qual è la modalità di esecuzione predefinita della query? Il mio database non ha alcun indice.

Esiste un altro modo per aumentare le prestazioni dell'istruzione Select Database?

Answer 1

L'idea sbagliata comune con Nolock è che non pone blocchi nel database durante l'esecuzione. Tecnicamente emette un blocco di stabilità dello schema (SCH-S), quindi la parte "no" del blocco si riferisce al lato dati della query.

Il più delle volte in cui lo vedo, è un'ottimizzazione prematura da parte di uno sviluppatore perché hanno sentito che rende la query più veloce.

A meno che tu non abbia prove e validità strumentate nell'accettare una lettura sporca (e potenzialmente leggendo la stessa riga due volte), non dovrebbe essere utilizzata - sicuramente non dovrebbe essere l'approccio predefinito alle query, ma un'eccezione alla regola quando può essere mostrata che è richiesto.

Answer 2

Ci sono numerosi articoli su questo in rete. Il rischio principale è quello con NOLOCK È possibile leggere i dati non eliminati dalla tabella (letture sporche). Vedi, per esempio, http://msdn.microsoft.com/en-us/library/aa259216(v=sql.80).aspx o http://www.techrepublic.com/article/using-nolock-and-readpast-table-hints-in-sql-server/6185492

Answer 3

NOLOCK Può essere molto utile quando si leggono vecchi dati da una tabella usata di frequente. Considera il seguente esempio,

Hai una procedura memorizzata per accedere ai dati di progetti inattivi. Non vuoi che questa procedura memorizzata blchirà la tabella dei progetti usati di frequente durante la lettura di vecchi dati.

NOLOCK è anche utile quando le letture sporche non sono un problema e i dati non vengono frequentemente modificati come nei seguenti casi,

Elenco di lettura di paesi, valute, ecc ... da un database a mostrare nel modulo. Qui i dati rimangono invariati e una lettura sporca non causerà un grosso problema in quanto si verificherà molto raramente.

Tuttavia, a partire da SQL Server 2005, i vantaggi di Nolock sono molto poco a causa della versioni di riga.