>>>>Based on that, you *should be* ok to make it a clustered index. One thing I haven't seen mentioned here. A clustered index is really a physical storing of the data in index order. You can insert, but it could mean rewriting a large portion of data.
>>>>
>>>>>The ID is an Identity column. If a user creates an order it is (ID) automatically set to the next ID sequential number. If user does not save the newly created record, the "missed" number will never be inserted.
>>>
>>>Exactly - if the definition of the clustered index represents a level of randomness when inserting new rows, you potentially wind up with index fragmentation, which can really impact performance.
>>
>>I understand what you are saying. But in the case that I am describing - PK column being an Identity and INT type - is there a downside to making the PK constraint clustered (vs. non-clustered)? I would leave it non-clustered but the execution plan clearly shows that the clustered index is used in much greater percentage.
>
>The ever increasing identity column is the best candidate for the clustered PK. You made a right switch, by default SQL Server makes PK column clustered. Perhaps you originally somehow made it non-clustered.

I think originally this column was not INT but NUMERIC(6,0) and I later changed it to INT. Could this have confused SQL Server and caused the PK column to be non-clustered?