We have a large table (450 million rows containing 34 columns of numeric or datetime data) that currently has around a dozen recommended paths for querying. The table currently has 17 indexes and I have no authority to change the structure of this table, though I am able to provide indexing strategies.
The first problem I see is that there is no clustered index, depite the fact that the table has a unique key that is composed of 2 columns. I was thinking I could change that to be clustered then deal with the other indexes. Since there are around a dozen common ways to query the table, I was thinking that adding an index for each query method would be a good thing. So say one of the common ways to query the table was by CustomerId, I would add an index on customer Id. That would be a non-clustered index though and would still be fairly inefficient right? What if I made that index contain CustomerId and the 2 columns within the clustered index? Would that make SQL Server more efficient in its execution plans or is that a useless task?
I would think that the best tactic is always to start by running the SQL Server Profiler on your database for a period of time. Once you then have a decent trace stored in file or to a dedicated trace table you can then run the SQL Server Database Tuning Advisor to get real statistics and index recommendations based on the actual use of your database rather than assumptions on how you perceive the lookup behaviours on your db.
It may actually be a case that there are certain expensive queries on your tables which are currently completely bypassing your existing configured indexes that you are not aware of. The tool will help you track down the best possible combinations.
Here is an example of this in practice:
Using the Database Tuning Advisor