Thank you. I was just looking at this stackoverflow thread which made me think of the change.
http://stackoverflow.com/questions/11787797/should-every-user-table-have-a-clustered-indexAnd I would like to find out where and how the performance will suffer.
>Clustered indeces are not a panacea. You have to understand how they work or performance suffers. A lot.
>
>
>>I am testing various scenarios of making SQL Select last 100 (top 100 order desc) records executing faster. The current PK constraint (on ORDER_NO) is non-clustered. I change it (in SSMS) from non-clustered to clustered. It took a little time (I understand that all non-clustered indexes have to be rebuilt). Now SQL Select works much faster and execution plan shows that the PK clustered index is used about 99%.
>>All seems to be good.
>>
>>Two question:
>>1. Why by default when I was creating the PK (a while ago) SQL Server created non-clustered?
>>2. What are the downsides of making this PK clustered? It is an order number assigned and is never changed.
>>
>>TIA
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham