Proper way of creating indexes for same column when "include" columns are different

Question

Let's say I have 2 stored procedures and 1 table.

• Table name: Table_A
• Procedure names: proc1 and proc2

When I run the proc1 with execution plan, it suggests me to create an index for Table_A for tblID (which is NOT a Primary Key) column and suggests to include column_A and column_B.

And the proc2 suggests to create an index for Table_A again, for tblID column but this time it suggests to include column_B and column_C (it suggests column_C instead of column_A for this procedure)

So my question is, if I have create an index which included all suggested columns like:

CREATE NONCLUSTERED INDEX indexTest
ON [dbo].[Table_A] ([tblID])
INCLUDE ([column_A],[column_B],[column_C])

Does that cause any performance issue?

Is there any disadvantage of gathering INCLUDE columns?

Or should I create 2 different indexes as:

CREATE NONCLUSTERED INDEX indexTest_1
ON [dbo].[Table_A] ([tblID])
INCLUDE ([column_A],[column_B])

CREATE NONCLUSTERED INDEX indexTest_2
ON [dbo].[Table_A] ([tblID])
INCLUDE ([column_B],[column_C])

UPDATE: I would like to add one more thing to this question.

If I do the same thing for primary fields as well:

I mean,

proc-1 suggested to create an index on tblID field. And proc-2 suggested to create an index on tblID and column_A.

If I gather them as :

 CREATE NONCLUSTERED INDEX indexTest_3
    ON [dbo].[Table_A] ([tblID],[column_A])
    INCLUDE ([[column_B])

Does that cause a performance issue? Or Should I create 2 separate index for suggested primary fields?

Answer 1

Definitely create one index that includes all three columns!

The fewer indexes you have, the better - index maintenance is a cost factor - more indices require more maintenance.

And the included columns are included in the leaf level of the index only - the have only a very marginal impact on performance.

Update: if you have a single index on (tblID, column_A), then you can use this for queries that use only tblID in their WHERE clause, or you can use it for queries that use both columns in their WHERE clause.

HOWEVER: this index is useless for queries that use only column_A in their WHERE clause. A compound index (index made up from multiple columns) is only ever useful if a given query uses the n left-most columns as specified in the index.

So in your case, one query seems to indicate tblID, while the other needs (tblID, column_A) - so yes, in this case, I would argue a single index on (tblID, column_A) would work for both queries.

Answer 2

It sounds like you're looking at the missing index dmvs. There are a couple things to realize here. The dmvs are really telling you about specific queries or groups of similar where a specific index might help.

In this sense, you are right to combine the indexes. This is the right idea.

However, also remember that indexes have a cost, and it's not the job of this dmv to weigh that cost. You definitely don't want to just automatically create an index to cover every recommendation. You also want to examine these indexes: once you include columns A,B, and C, are you keeping the entire table (or nearly so) in the index? Could you perhaps get better results by changing the primary key to match this index? Be careful evaluating that last part, because changing the primary key could then leave the prior key as an even more important missing index.