Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
PMass
Starting Member
1 Post |
Posted - 2013-06-05 : 10:59:01
|
Good morning from Pittsburgh. :) I have recently (a month ago) taken a position with a medical company with a fairly large (1 Tb) SQL 2008 database. I discovered that the 4 largest tables have a primary key on a NON clustered index, and there is no clustered index on the table... that is the case for all 4 tables. So my questions are:1. For a table with almost a billion rows, seems to me having a clustered index would make a huge difference in query execution time, and any maintenance time would be well worth it for the performance gain. Am I right in wanting to drop the existing primary key and recreate it as a clustered primary key?2. I have created a temporary unique non-clustered index to serve queries, but is that enough? What other risk do I need to worry about before I drop the primary key and recreate it as a clustered index?Many thanks!Phil |
|
TG
Master Smack Fu Yak Hacker
6065 Posts |
Posted - 2013-06-05 : 16:26:07
|
There is no reason why a primary key needs to be clustered. And there may even be some scenarios where a table is better off withou a clustered index - not common but possible. There are a lot of factors that can go into determining which column(s) should comprise the clustered index of a table. Mostly around how the table is maintained (i/u/d) and typical correlations to other tables and typical criteria for SELECTs.If you want help maybe post the current DDL and how it is used.Be One with the OptimizerTG |
|
|
|
|
|