Почему ОБНОВЛЕНИЕ берет намного дольше, чем ВЫБОР?

У меня есть следующий избранный оператор, который заканчивается почти немедленно.

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  

Однако эквивалентный оператор обновления берет 1m40 s

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

Даже если я добавляю:

and InvoicesCharges.orderaccnumber <> Accountnumbersorders.accountnumber

в конце оператора обновления, сокращающего количество записей для обнуления, это занимает то же количество времени.

Я делаю что-то не так здесь? Почему там такая огромная разница?

8
задан gbn 15 June 2011 в 17:02
поделиться

3 ответа

Файл журнала транзакций
  • записывает
  • обновления индекса
  • поиск иностранных ключей
  • каскады иностранных ключей
  • индексированные просмотры
  • вычисленные столбцы
  • проверка ограничений
  • блокировки
  • блокировки
  • блокировка эскалации
  • изоляция снимка
  • зеркалирование БД
  • рост файла
  • другое обрабатывает чтение/запись
  • page splits /не подходящие кластерные index
  • forward pointer/row overflow events
  • poor indexes
  • bad indexes
  • bad disk layout out date
  • bad layout (например, один большой RAID на все)
  • Check constraints with UDFs that have table access
  • . ..

Хотя, обычный подозреваемый - триггер....

Кроме того, ваше условие extra не имеет значения: Как SQL-сервер узнает, что его нужно игнорировать? Обновление все еще генерируется с большей частью багажа... даже триггер все равно будет стрелять. Замки должны удерживаться во время поиска строк для других условий, например

Edited Sep 2011 and Feb 2012 с дополнительными опциями

.
23
ответ дан 5 December 2019 в 05:26
поделиться

Обновление должно блокировать и изменять данные в таблице, а также регистрировать изменения в журнале транзакций. Избранное не должно делать ничего из этого.

6
ответ дан 5 December 2019 в 05:26
поделиться

Потому что чтение не влияет на индексы, триггеры и что у вас есть?

1
ответ дан 5 December 2019 в 05:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: