As per suggestion index must be Most Selective to improve the performance. As a general guideline, we should create indexes on tables that are often queried for less than 15% of the table's rows The ratio of the number of distinct values in the indexed column / columns to the number of records in the table represents the selectivity of an index.
Example with good Selectivity
A table having 100'000 records and one of its indexed column has 88000 distinct values, then the selectivity of this index is 88'000 / 10'0000 = 0.88.
Now come to point. I have one table having 1,80,000 records.
Fields that are being frequently used in search criteria are
(1) search record using Name of user.
Field Type :-> Not null , nvarchar(32).
Unique records are 627
(2) search record using Active_date.
Field Type :-> DateTime ,Null.
Unique records are 85627 .
(3) search records using Current_state
Field Type :-> Not Null , nvarchar(32).
Unique records are only 2 that are " Pending " and " Closed ".
currently all above fields are indexed. In terms of Selectivity case (1) and (3) are not most selective what i should do with them in terms of improve performance?
Thanks in Advance, Sam
Selectivity doesn't tell the whole story. Say there are 10 pending applications and 1.000.000 closed ones. Then an index on status is not very selective, but it's still very useful! The index would help people quickly browse pending applications, which may be something they frequently do.
One other example is a ticketing system. Most of the work is done on open tickets. So while the status for a ticket isn't very selective, it's still an excellent candidate for an index.
P.S. Only the leftmost known columns of an index can be used to resolve a search. For example:
select * from Users where name = 'fred'
An index on
(name) can be used to resolve this query, but an index on
(active_date, name) can not.