Pourquoi une mise à jour prend beaucoup plus de temps qu'un SELECT?

Question

J'ai l'instruction select suivante qui se termine presque instantanément.

declare @weekending varchar(6) 
set @weekending = 100103 

select InvoicesCharges.orderaccnumber, Accountnumbersorders.accountnumber 
from Accountnumbersorders, storeinformation, routeselecttable,InvoicesCharges, invoice 
where InvoicesCharges.pubid = Accountnumbersorders.publication 
and Accountnumbersorders.actype = 0 
and Accountnumbersorders.valuezone = 'none' 
and storeinformation.storeroutename = routeselecttable.istoreroutenumber 
and storeinformation.storenumber = invoice.store_number 
and InvoicesCharges.invoice_number = invoice.invoice_number 
and convert(varchar(6),Invoice.bill_to,12) = @weekending 

Cependant, la déclaration de mise à jour équivalente prend 1m40s

declare @weekending varchar(6) 
set @weekending = 100103 
update InvoicesCharges 
set InvoicesCharges.orderaccnumber = Accountnumbersorders.accountnumber 
from Accountnumbersorders, storeinformation, routeselecttable,InvoicesCharges, invoice 
where InvoicesCharges.pubid = Accountnumbersorders.publication 
and Accountnumbersorders.actype = 0 
and dbo.Accountnumbersorders.valuezone = 'none' 
and storeinformation.storeroutename = routeselecttable.istoreroutenumber 
and storeinformation.storenumber = invoice.store_number 
and InvoicesCharges.invoice_number = invoice.invoice_number 
and convert(varchar(6),Invoice.bill_to,12) = @weekending 

Même si j'ajoute:

and InvoicesCharges.orderaccnumber <> Accountnumbersorders.accountnumber 

à la fin de la déclaration de mise à jour en réduisant le nombre d'écritures à zéro, il prend le même laps de temps.

Est-ce que je fais quelque chose de mal ici? Pourquoi y a-t-il une telle différence?

Answer 1

• fichier journal des transactions écrit
• mises à jour d'index
• des LookUps clés étrangères
• cascades clés étrangères
• vues indexées
• colonnes calculées
• contrôle des contraintes
• serrures
• verrous
• verrouillage escalade
• isolement instantané
• DB miroir
• croissance fichier
• autres processus de lecture/écriture
• fractionnements/index ne convient pas cluster
• événements de débordement pointeur vers l'avant/rangée
• pauvres indices
• statistiques périmées
• mauvaise mise en page du disque (par exemple, un grand RAID pour tout)
• Les contraintes de vérification avec des FDU qui ont accès à la table
• ...

Bien que, le suspect habituel est un déclencheur ...

De plus, votre condition supplémentaire n'a aucune signification: Comment SQL Server sait-il l'ignorer? Une mise à jour est toujours générée avec la plupart des bagages ... même le déclencheur sera toujours activé.Serrures doivent avoir lieu en lignes sont recherchées pour les autres conditions, par exemple

Modifié septembre 2011 et en février 2012 avec plus d'options

Answer 2

Parce que la lecture n'affecte pas les indices, les déclencheurs et vous?

Answer 3

La mise à jour doit verrouiller et modifier les données de la table et également enregistrer les modifications dans le journal des transactions. Le select n'a pas à faire de ces choses.

Answer 4

Dans serveurs lents ou grande base de données i utilise généralement UPDATE RETARD, qui attend une « pause » mettre à jour la base de données elle-même.