Sqlserver
 sql >> Database >  >> RDS >> Sqlserver

Il NOLOCK (suggerimento SQL Server) è una cattiva pratica?

Prima di lavorare su Stack Overflow, ero contrario a NOLOCK sul principale che potresti potenzialmente eseguire un SELECT con NOLOCK e ottenere risultati con dati che potrebbero non essere aggiornati o incoerenti. Un fattore a cui pensare è quanti record possono essere inseriti/aggiornati contemporaneamente un altro processo potrebbe selezionare i dati dalla stessa tabella. Se ciò accade spesso, c'è un'alta probabilità di deadlock a meno che non utilizzi una modalità database come READ COMMITED SNAPSHOT .

Da allora ho cambiato la mia prospettiva sull'uso di NOLOCK dopo aver visto come può migliorare SELECT prestazioni ed eliminare i deadlock su un server SQL caricato in modo massiccio. Ci sono volte in cui potresti non preoccuparti che i tuoi dati non siano esattamente impegnati al 100% e hai bisogno di risultati rapidamente anche se potrebbero non essere aggiornati.

Fatti una domanda quando pensi di usare NOLOCK :

La mia query include una tabella con un numero elevato di INSERT /UPDATE comandi e mi interessa se i dati restituiti da una query potrebbero mancare di queste modifiche in un determinato momento?

Se la risposta è no, usa NOLOCK per migliorare le prestazioni.

Ho appena eseguito una rapida ricerca per NOLOCK parola chiave all'interno della base di codice per Stack Overflow e trovato 138 istanze, quindi lo usiamo in parecchi punti.