Can i replace the non-clustered indices with one covering index ?
No. Suppose you sometimes find people by LastName and sometimes by FirstName. An index on (LastName, FirstName) won't help you find people by FirstName.
If not, is there any way to get rid of RID Lookup rather than a covering index ?
Not in a way that's particularly useful.
Does each query require a different covering index depending on the columns in the select list and the search conditions ?
Pretty much. Your job is to come up with a compromise.
I have no clustered indexes in the table , does adding a unique column and setting it as a primary key helps in getting rid of RID Lookups ?
A PK doesn't necessarily mean a clustered index. And having a CIX just means your RID Lookups will become Key Lookups, which are potentially worse. But without CIXs you have heaps which can fragment when you change or delete data. So CIXs are fine, but won't improve performance of your Lookups.
Without further info, this is more of speculation but judging on what we have:
- a table that is quite wide (1.3 to 4.0 rows per page on average)
- the query that is slow is using:
- only
PWFID on the join condition,
- two columns
Title, SITime on the select list and
- no other column anywhere (
WHERE, HAVING etc.)
Then a covering non-clustered index on (PWFID) INCLUDE (SITime, Title) will probably improve the efficiency of the query as it will need to read a narrower index (and no lookups to the table, whether it's clustered or a heap). No idea how much improvement it would be, as the query involves joining of 30 something tables - and the index will not be that narrow either, with the included 500 character column.
About converting the table to a heap:
This makes me wonder if getting rid of the clustered index and make this table a heap makes sense or not, because I can just "save" the clustered index and free some space for having a covering nonclustered index?
This is irrelevant I think, at least for this and similar queries. It might change/improve the behaviour of insert queries (as no clustered index will have to be maintained) but it may also degrade performance for other queries that depend on finding more columns from the clustered index.
And you won't be saving any (or much) space. The data has to be stored somewhere, whether the table is a heap or clustered.
Adding a NC index is much less drastic change and I wouldn't expect any side effects - apart from the wanted use of it in the query - but still needs to be tested.
Removing the clustered index and converting a table to a heap is effectively changing the structure of all NC indexes and removing of (the clustered) one, so it may have several and more serious effects on many operations/queries performed and would need much more testing.
Best Answer
You are correct in your description but the conclusion is not correct. It may still be faster to use the index anyway even if it has to go off to the table for the rest of it. The data pages contain many fewer rows than the index so there's lots of extra I/O when scanning. Generally the index will tend to give you benefits if it selects few rows even if it's not a great fit.