Utilizzo di NOLOCK su Microsoft SQL Server

Sembra che tu sappia già cosa suggerisca la tabella NOLOCK , ma la domanda è "perché" le persone lo usano così frequentemente. Nell'esperienza delle persone, o persone che hanno condiviso esperienze con loro, hanno già alleviato i problemi di concorrenza utilizzando l'hint della tabella read unsmitted .

Nonostante ciò che fa il suggerimento (la mancanza di un blocco condiviso sui dati per impedire il blocco o il blocco), lo usano ancora. Perché? Perché è "facile" sacrificare cose importanti (dati coerenti e puliti, sicurezza, ecc.) Con "correzioni" comuni.

Perché lasciare perdere la possibilità che la query venga bloccata? Basta specificare WITH (NOLOCK) . 13 caratteri che cancellano ogni pensiero di essere bloccati o bloccati.

Ovviamente questa è una cattiva pratica e potrebbe portare alla lettura di dati sporchi e incoerenti, ma è facile. Normalmente questo viene fatto dagli sviluppatori SQL che non vogliono complicarsi con la risoluzione dei problemi di blocco e altre situazioni di concorrenza, e preferiscono prendere la facile uscita .

My specific question is why is it so overused in every organization I tend to consult with? I've seen it used for every select statement on every tables in the last 3 clients I've been at. What are the possible reasons for this?

Perché quelli che usano e abusano tendono a non capire i sistemi di gestione dei database relazionali o i modelli di concorrenza, e sbaglia dalla parte della generosità invece della pulizia dei dati.

Is the memory/hardware insufficient to get transactions processed?

No, in genere non è il fattore trainante.

Is data consistency less important than it used to be?

La coerenza dei dati dovrebbe essere un obiettivo senza tempo. Il 99% delle volte è per pigrizia o ignoranza che gli sviluppatori lo usano.

What is the general consensus and best practice on using NOLOCK?

La best practice è non usarla a meno che tu non abbia assolutamente provato senza dubbio che ne hai bisogno ed è ok. Semplice come quello.

Perché molti team non conoscono vantaggi e svantaggi delle diverse funzionalità di Microsoft SQL Server.

Immagina un'app lenta. Il management ha una scelta: o gettare più hardware (che si traduce in costi immediati e sostanziali), o incolpare gli sviluppatori di non fare il proprio lavoro correttamente e si aspettano che lo facciano più velocemente (il che si traduce in costi notevoli distribuiti in settimane o mesi). Qual è, secondo te, la scelta del management nella maggior parte delle aziende?

Ora il team cerca i modi per ottimizzare la propria app e un programmatore scopre che NOLOCK rende tutto magicamente più veloce. Fantastico - racconta a se stesso - posso dirlo alla mia squadra e il nostro prodotto sarà più veloce. Se la squadra ha un abile DBA, hanno la possibilità di evitare l'errore. Se non lo fanno (e in troppi casi, non lo fanno), possono finire con NOLOCK ovunque.

Purtroppo, le conseguenze della mancanza di coerenza dei dati non sono immediate. In alcuni casi, l'applicazione potrebbe funzionare per mesi senza problemi. Quindi, quando si verifica un'incoerenza, nessuno conosce l'origine del problema. I programmatori incolpano gli amministratori di sistema. Gli amministratori di sistema incolpano i programmatori. Il sistema potrebbe finire per essere riparato per evitare incongruenze nella posizione specifica aggiungendo test discutibili a livello di applicazione che rendono tutto più lento e funzioni per mesi prima di incontrare un'incoerenza da qualche altra parte.

Detto questo, ci sono circostanze valide in cui la coerenza dei dati non ha importanza . La funzione è lì per uno scopo; se il numero di transazioni è elevato e ottenere dati incoerenti è perfettamente accettabile, non c'è niente di sbagliato nell'utilizzare NOLOCK. Ad esempio, sarebbe davvero importante avere un commento su un forum mentre un rollback è successo per rimuoverlo? Probabilmente no. D'altra parte, se si vede che viene utilizzato in un'applicazione bancaria all'interno di un metodo che trasferisce denaro da un account a un altro, questo è più problematico.