Question

We have a table with about 100,000 record which is used frequently in our applications. We had an identity (ID) columns and had a clustered index on it and everything worked good. But for some reasons we had to use a Uniqueidentifier column as Primary key. So we add a non clustered index on it and removed the clustered index on ID column. But now, we have lots of performance degradation issuses from our customer in peak times. Is it because the table has no clustered index now?

Answer 1

The fact that you added a primary key by no means implies you had to drop the clustered index. The two concepts are distinct. You can have an uniqueidentifier PK implemented by a non clustered index and a separate clustered index of choice (eg. the old ID column).

But the real question is How did you change your application when you added the uniqueidentifier PK? Did you also modified the application code to retrieve the records by this new PK (by the uniqueidentifier)? Did you update all joins to reference the new PK? Did you modified all foreign key cosntraints that referenced the old ID column? Or does the application continue to retrieve the data using the old identity ID column? My expectation is that you changed both the application and the table, and the access is now prevalent on the form of SELECT ... FROM table WHERE pk=@uniqueidentifier. If only such access occurs, then the table should perform OK even with a non-clustered uniqueidentifier primary key and no clustered index. So there must be something else at play:

• your application continues to access the table based on the old identity ID column
• there are joins in your query based on the old identity ID column
• there are foreign key constraints referencing the table on the old ID column

Ultimately you have a performance troubleshooting issue at hand and approach it as a performance troubleshooting problem. I have two great resources for you:the Waits and Queue methodology and the Performance Troubleshooting Flowchart