I have a search that calls a stored proc which accepts up to 5 parameters.
there are a number of tables in the query but the params are all filtering on a single table within the query.
question is
is it better to have an index for each of the params (fields in the table) or one index that covers all of them
there are obviously other queries that may use 1 or more of these fields for their own purposes so maybe it is worth leaving an index for each of the fields.
sorry if that is not a clear question
question: is it better to have a covering index – that covers ALL the search fields.
OR
an index for each
which is the better practice?
any help much appreciated
thanks
nat
I suspect the answer depends on how the “up to” 5 parameters are most commonly specified. If they are commonly specified in a particular sequence of increasing specificity (e.g. records for a clientid, or a clientid + accountid, or clientid + accountid + month etc) then if you build the covering query in that order, then most of the <5 queries will still be able to use it efficiently.
If, OTOH, which particular params are specified and which not is relatively random, AND you have other processes wanting indexes on some of these columns, then you may be as well to index each column separately.
In an ideal world, of course, you would have a performance testing rig to find out the correct decision empirically. But so few projects get built in ideal worlds. Even so, you can’t beat a bit of testing, even if your DEV rig looks nothing like production.