Do you really need the partitioned column as the first column in the index in SQL Server?

Question

Let's say I want to run this query:

SELECT State, City FROM dbo.Table1 WHERE Status = 1 AND City = 'Jackson'

The column "Status" in dboTable1 is the column used in the partition, meaning that all queries should have Status = 1.

My question is, when I create a non-clustered index to satisfy this query, is there a difference between these two indexes ? And if so, which is the ideal one to use?

1:

CREATE NONCLUSTERED INDEX IX_Table1_City ON dbo.Table1 (Status, City)
INCLUDE (State)
WHERE Status = 1 
ON PartitionScheme(Status)

2:

CREATE NONCLUSTERED INDEX IX_Table1_City ON dbo.Table1 (City, Status)
INCLUDE (State)
WHERE Status = 1 
ON PartitionScheme(Status)

I would want to use option #2, but does it matter or do I need to go with option #1?

Thanks all.

Answer 1

SELECT State, City FROM dbo.Table1 WHERE Status = 1 AND City = 'Jackson'

My question is, when I create a non-clustered index to satisfy this query, is there a difference between these two indexes? And if so, which is the ideal one to use?

For the query with equality predicates on both Status and State, either index can be used for a seek operation that touches only the requested rows.

Also, you can omit the Status column entirely when all rows in the partition have the same status value (ie list partitioning). SQL Server treats the partitioning column as if it were the leftmost key column for partition elimination and then leverage the b-tree index on City alone to touch only the matching City values in that partition. The advantage of this approach versus the compound index key is less index maintenance overhead. Keep in mind the partitioning column as well as the clustered index key columns (if applicable) are implicitly included in the index so this index covers the query.

CREATE NONCLUSTERED INDEX IX_Table1_City ON dbo.Table1 (City)
INCLUDE (State)
WHERE Status = 1 
ON PartitionScheme(Status);