views:

37

answers:

2

I'm still a learning user of SQL-SERVER2005.

Here is my table structure

CREATE TABLE [dbo].[Trn_PostingGroups](
[ControlGroup] [char](5) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[PracticeCode] [char](5) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[ScanDate] [smalldatetime] NULL,
[DepositDate] [smalldatetime] NULL,
[NameOfFile] [varchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[DepositValue] [decimal](11, 2) NULL,
[RecordStatus] [char](1) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
CONSTRAINT [PK_Trn_PostingGroups_1] PRIMARY KEY CLUSTERED 
(
    [ControlGroup] ASC,
    [PracticeCode] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

Scenario 1 : Suppose I have a query like this...

Select * from Trn_PostingGroups where PracticeCode = 'ABC'

Will indexing on Practice Code seperately help me in making my query faster??

Scenario 2 :

Select * from Trn_PostingGroups 
where 
    ControlGroup = 12701 
    and PracticeCode = 'ABC'
    and NameOfFile = 'FileName1'

Will indexing on NameOfFile seperately help me in making my query faster ??

A: 

You can only utilize one index per table per query (unless you consider self joins or CTEs). if you have multiple that can be used on the same table in the same query, then SQL Server will use statistics to determine which would be better to use.

In Scenario 1, if you create an index on PracticeCode alone, it will usually be used, as long as you have enough rows that a table scan costs more and that there is a diverse range of values in that column. An index will not be used if there are only a few rows in the table (it is faster to just look at them all). Also, an index will not be used if most of the values in that column are the same. It will not use the PK in this query, it would be like looking for a first name in the phone book, you can't use the index because it is last+first name. You might consider reversing your PK to PracticeCode+ControlGroup if you never search on ControlGroup by itself.

In Scenario 2, if you have an index on NameOfFile it will probably use the PK and ignore the NameOfFile index. Unless you make the NameOfFile index unique, and then it is a tossup. You might try to create an index (in addition to your PK) on ControlGroup+PracticeCode+NameOfFile. if you have many files per ControlGroup+PracticeCode, then it may select that index over the PK index.

KM
I'm Sorry. I could not get you... In first case condition is on a field which a part of PKEY, as a result many rows will be returned... But in second case, I give all the values of PKEY, so it is going to return me only one row.. But I do a further check on One more Column. I think it would be appropriate for SQL server to fetch the data of PKEY and check the one column against the row fetched...
The King
I completely missed the `PRIMARY KEY` portion of the table definition in the question.
KM
@Mitch how so? self joins, CTEs, certainly not in simple queries like given in the question.
KM
To be a pedant: If a simple query is executed that uses a non-covering, non-clustered index, then it will also use the clustered index. So saying "You can only utilize one index per table per query" is not strictly true.
Mitch Wheat
+1  A: 

If you were only selecting on the first field (ControlGroup), it is the primary sort of the clustered index and you wouldn't need to index the other field.

If you select on the other primary key fields, then adding a separate index on the other fields should help with such selects.

In general, you should index fields that are commonly used in SORT and WHERE clauses. This of course is over simplified.

See this article for more information about optimizing (statistics and query analyser).

Oded
Thanks... Any help on Scenario 2.
The King
Very good Link... Thanks
The King