Indexing individual fields of SQL Server composite keys

Question

I'm upsizing a Jet database to SQL Server Express 2008 R2 and before doing so, I'm re-evaluating the schema (it was designed in 1997-98, and the guy who designed it (i.e., me) was something of a moron!).

My question is about N:N join tables with a two-column composite key. In Jet, joins on the first column of a two-column composite key will use the composite index, but joins on the second column will not, so in general, in Jet databases with large N:N join tables with reasonably large numbers of records, in addition to the composite index I add a second, non-unique index on the second column.

Is this a good idea in SQL Server?

(Maybe it's not a good idea in Jet?)

Answer 1

The same rules apply in SQL Server. If you have an index on (ColumnA, ColumnB) a query on only ColumnA or ColumnA and ColumnB together can use the index, but a query on only ColumnB cannot. If there is a need to join on just ColumnB, then you should definitely create the index.

Answer 2

If you have a composite index on columns (A,B) no seek, range scan, sort or aggregate operation can use it for expressions that contain only B. This is true for SQL Server, just as it was true for Jet (Red) drivers (and I think for Jet Blue also). Some other engines might use it in a so called skip scan operation.

So the answer is that you need separate indexes on (B) alone.

Answer 3

To help you more, just a tip, in SQL server using the Managment studio you can evaluate the performance by "Display Estimated execution plan". It shown how the indexs and join works.

Also you can use the DTA (Database Engine Tuning Advisor) for more info and optimization.