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
The Clustered Index Update physical operator updates input rows in the clustered index specified in the Argument column. If a WHERE:() predicate is present, only those rows that satisfy this predicate are updated. If a SET:() predicate is present, it indicates the value to which each updated column is set.
To drop a clustered or nonclustered index, issue a DROP INDEX command. When you do this, the metadata, statistics, and index pages are removed. If you drop a clustered index, the table will become a heap. Once an index has been dropped, it can't be rebuilt – it must be created again.
Clustered indexes are implemented in the following ways: PRIMARY KEY and UNIQUE constraints. When you create a PRIMARY KEY constraint, a unique clustered index on the column or columns is automatically created if a clustered index on the table does not already exist and you do not specify a unique nonclustered index.
Yes, every table should have a clustered index. The clustered index sets the physical order of data in a table. You can compare this to the ordering of music at a store, by bands name and or Yellow pages ordered by a last name.
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.
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.
A clustered index must be re-ordered when it is updated. That means the whole index is basically reorganized, and that is why it's expensive. A primary key (PK) is usually a clustered index but not necessarilly always, however, I would advise that a PK should be clustered. But also, a custered index is not necessarilly always a primary key.
yes, that's correct. 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.
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'.
The clustered index is the physical table, so whenever you update any row, you're updating the clustered index.
See this MSDN article
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With