Subject | Re: [ib-support] Compound Index or Individual Column Indices - Which one are better for Performance |
---|---|
Author | Svein Erling Tysvaer |
Post date | 2002-12-09T08:57:44Z |
Simple answer: Correct indexes are the best.
Unfortunately, this will depend upon your data as well as your program and
you are the only person able to find the correct answer in your particular
case. However, a few guidelines:
Don't bother to index fields with low selectivity - indexing fields with
only a few possible values (e.g. fields used for boolean values) decrease
performance.
Make the index 'go the right way'. E.g. if you have a date field and
frequently wants to query recent records, make sure the index is DESCending
(Max = Descending, Min = Ascending).
Too many indexes aren't much better than too few indexes. If Fb says it is
going to use an index in a plan, it is going to use it - even if the result
from another index in the plan already makes the result unique.
If a field is mostly used together with another field, I'd go for a
compound index. If they are completely separate, I'd go for separate
indexes. Note that there is never any need to index the first field of a
compound index separately - if you have an index on (LASTNAME, FIRSTNAME)
this index can be used for queries restricted by LASTNAME regardless of
whether FIRSTNAME is specified. The reverse is not true, the index can only
be used for FIRSTNAME if LASTNAME is also specified.
HTH,
Set
Unfortunately, this will depend upon your data as well as your program and
you are the only person able to find the correct answer in your particular
case. However, a few guidelines:
Don't bother to index fields with low selectivity - indexing fields with
only a few possible values (e.g. fields used for boolean values) decrease
performance.
Make the index 'go the right way'. E.g. if you have a date field and
frequently wants to query recent records, make sure the index is DESCending
(Max = Descending, Min = Ascending).
Too many indexes aren't much better than too few indexes. If Fb says it is
going to use an index in a plan, it is going to use it - even if the result
from another index in the plan already makes the result unique.
If a field is mostly used together with another field, I'd go for a
compound index. If they are completely separate, I'd go for separate
indexes. Note that there is never any need to index the first field of a
compound index separately - if you have an index on (LASTNAME, FIRSTNAME)
this index can be used for queries restricted by LASTNAME regardless of
whether FIRSTNAME is specified. The reverse is not true, the index can only
be used for FIRSTNAME if LASTNAME is also specified.
HTH,
Set