Ok... rethinking this a little bit and even though the question was devoid of most information, the fact is that there isn't much people do with hashkey columns except to do compares during "Upserts" and the like.
With that thought in mind, I probably wouldn't waste the Clustered Index on such a thing but, as with all else in SQL Server, I'll say "It Depends" on things like how the "Upserts" are being done and whether or not someone is using the column for anything else.
The other thing to consider is that such a hashkey is going to be almost random in nature. If you use it as the leading column of a Clustered Index, it's going to be very much like have a Clustered Index on a Random GUID. That means many things...
- Every Non-Clustered index will also have the 40 byte hash key appended to it, which will take up quite a bit of extra space, extra memory, and slow things down quite a bit.
- REALLY change your index maintenance strategy. Most people get it horribly wrong for such columns. For example, you must NOT use REORGANIZE on such columns. To summarize the biggest reason for that is that REORGANIZE will NOT make new pages and so cannot "clean" the area between the Fill Factor and being 100% full. That problem alone will perpetuate rampant page splits and fragmentation every bloody day. If you don't use REORGANIZE on such columns, they can actually work out quite well at seriously preventing fragmentation given the correct Fill Factor and dwell time between REBUILDs and can go literally for months with absolutely zero page splits and the resulting fragmentation. Such indexes are also wicked good for very high rate inserts because they avoid "hot spots" in the table.
So, all that being said and to summarize my thoughts... I'd probably NOT make the column the Clustered Index BUT, and strongly depending on what else the column will be used for, there can be extreme trade-off advantages to doing so. Without additional information, though, it's not possible to make an accurate recommendation... only a general one.
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
"Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)