Why does an UPDATE take much longer than a SELECT?

Question

I have the following select statement that finishes almost instantly.

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

select InvoicesCharges.order         


        

Answer 1

Because reading does not affect indices, triggers, and what have you?

Answer 2

• transaction log file writes
• index updates
• foreign key lookups
• foreign key cascades
• indexed views
• computed columns
• check constraints
• locks
• latches
• lock escalation
• snapshot isolation
• DB mirroring
• file growth
• other processes reading/writing
• page splits / unsuitable clustered index
• forward pointer/row overflow events
• poor indexes
• statistics out of date
• poor disk layout (eg one big RAID for everything)
• Check constraints with UDFs that have table access
• ...

Although, the usual suspect is a trigger...

Also, your condition extra has no meaning: How does SQL Server know to ignore it? An update is still generated with most of the baggage... even the trigger will still fire. Locks must be held while rows are searched for the other conditions for example

Edited Sep 2011 and Feb 2012 with more options

Answer 3

In Slow servers or large database i usually use UPDATE DELAYED, that waits for a "break" to update the database itself.

Answer 4

The update has to lock and modify the data in the table, and also log the changes to the transaction log. The select does not have to do any of those things.