2010-01-05 20 views
8

Mam następujące polecenie select, które kończy się niemal natychmiast.Dlaczego UPDATE trwa znacznie dłużej niż SELECT?

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 

jednak równoznaczne oświadczenie aktualizacja odbywa 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 

Nawet jeśli dodam:

and InvoicesCharges.orderaccnumber <> Accountnumbersorders.accountnumber 

na końcu instrukcji UPDATE zmniejszenie liczby zapisów do zera, to zajmuje tyle samo czasu.

Czy robię coś nie tak? Dlaczego istnieje tak ogromna różnica?

+0

Dodatkowa klauzula OWY nadal jest dobrym pomysłem, dlaczego aktualizować 50 000 wierszy, gdy trzeba tylko zaktualizować 2? – HLGEM

Odpowiedz

21
  • plik dziennika transakcji pisze
  • aktualizacji indeksu
  • klucz obcy wyszukiwań
  • klucz obcy kaskady
  • widoki indeksowane
  • kolumny obliczane
  • ograniczenia wyboru
  • zamki
  • zatrzaski
  • eskalacja blokad
  • izolacji migawka
  • DB mirroring
  • wzrostu plik
  • inne procesy zapisu/odczytu
  • strona podziały/nieodpowiedni skupione indeks
  • przodu wskaźnik/row wydarzenia przelewowe
  • ubogich indeksy
  • statystyki nieaktualne
  • biedny układ dysku (na przykład jeden wielki RAID za wszystko)
  • Sprawdź ograniczenia z UDF, które mają dostęp stołowego
  • ...

Chociaż zwykle podejrzany jest spust ...

Dodatkowy stan nie ma znaczenia: w jaki sposób SQL Server może go zignorować? Aktualizacja nadal jest generowana z większością bagażu ... nawet spust nadal będzie strzelał.Zamki należy uznać natomiast wiersze są przeszukiwane dla innych warunków np

Edited września 2011 a lutym 2012 więcej opcji

+2

Tak, przyczyną był spust. Jestem nowy w tym i "kod" nie jest mój. Dzięki za heads up. Dodałem dodatkowy warunek, ponieważ myślałem, że zapisanie dysku na dysku trwa zbyt długo, więc nie było niepotrzebnych zapisów na dysku. Jeszcze raz dziękuję. – Nodja

+0

+1. Niezła odpowiedź. –

+0

I oczywiście wyzwalacze, które są "zaprojektowane" do przesuwania kursora przez wszystkie rzędy zamiast uruchamiania w sposób oparty na ustawieniach! – HLGEM

1

Ponieważ odczyt nie wpływa na wskaźniki, wyzwalacze i co masz?

6

Aktualizacja musi blokować i modyfikować dane w tabeli, a także rejestrować zmiany w dzienniku transakcji. Selekcja nie musi robić żadnej z tych rzeczy.

+0

Nitpick: Możesz * możesz * mieć DML w instrukcji SELECT, to po prostu nie jest zapisane ... chyba że to INSERT INTO ... SELECT ... –

+1

A także modyfikować indeksy na stole. Im więcej indeksów, tym dłuższy zapis. – womp

+0

, dlaczego więc długo trwa, nawet przy dodatkowym stanie? W tabelach powinno być zero zmian, ale to trwa długo. – Nodja

1

w zwolnionym serwerów lub dużej bazy danych Zwykle używam UPDATE opóźniony, że czeka na „break” zaktualizować samą bazę danych.

Powiązane problemy