views:

618

answers:

2

I'm executing the following statement:

UPDATE TOP(1) dbo.userAccountInfo
SET           Flags = Flags | @AddValue
WHERE         ID = @ID;

The column 'ID' is an INT PRIMARY KEY with IDENTITY constraints. Flags is a BIGINT NOT NULL.

The execution path indicates that a Clustered Index Update is occurring. A very expensive operation. There's no indexes covering Flags or ID, except for the primary key. I feel like the actual execution path should be:

Clustered Index Seek => Update

+2  A: 

The clustered index is the physical table, so whenever you update any row, you're updating the clustered index.

See this MSDN article

BradC
I feel like I should only be doing a Clustered Index Update if I affect the primary key.But I catch your point.I guess I've sort of been brainwashed in to thinking clustered index updates are a hazardous thing.
Kivin
+5  A: 

Tables come in two flavors: clustered indexes and heaps. You have a PRIMARY KEY constraint so you have created implicitly a clustered index. You'd have to go to extra length during the table create for this not to happen. Any update of the 'table' is an update of the clustered index, since the clustered index is the table. As for the clustered index update being a 'very expensive operation', now that is an urban legend surrounding basic misinformation about how a database works. The correct statement is 'a clustered index update that affects the clustered key has to update the all non-clustered indexes'.

Remus Rusanu
It's really a shame that there's so many... urban legends, as you put it... surrounding RDBs. I've squashed a handful of them in the few weeks I've been writing SQL. May I safely assume that, so long as I don't update ID, I wont cause a (potentially) grossly expensive operation to occur on the clustered data?
Kivin
yes, that's correct.
BradC
Updating ID would require a an update in *all* other indexes. Updating any other column that is part of an index would require an update of those indexes. A column that is not part of any index (as key or as contained column) would not cause any extra update. E.g. if you have an index on Flags then your update occur an extra update to maintain that index too. I wouldn't worry much about updates unless I evidence point to one being bad. Most often the unoptimized reads (scans) are the problem. BTW, what is the TOP (1) for? ID is PK, isn't it?
Remus Rusanu