Comments on: Redundant index is not always bad

By: bob

bob — Thu, 01 Nov 2007 22:59:19 +0000

I would be very upset if someone wanted to index on (state,city,address). Address is too big to be useful in an index (it will limit the # records/page and just doesn’t make sense.

It would be interesting to repeat the tests with just (state,city).

This of course ignores all international issues which should impose an index of (country_id,state,city).

note that this is also messy since it makes for a very deep index as opposed to a wide index (i.e. you have to traverse more btree nodes to get to your data).

Also the inserts should take longer, you’re building a much larger index in the 2nd case and causing many more page balances just due to the fact that each page will hold fewer index items.

By: Ryan

Ryan — Thu, 30 Aug 2007 00:23:45 +0000

I mean redundant indexes. Say one with ‘cola’ and another with ‘(cola, colb)’. The merge intersect will not work in a query that doesn’t use ‘colb’ so you need to add both indexes if you want to use the merge intersect. Also I don’t want to optimize by adding muti-key indexes to every possible combinations of filters a user might have and would rather use the merge intersect for many things. Then this gets the the secondary problem that if you have two redundant indexes and you are filtering on ‘cola’ and ‘colb’ it will often choose to use both indexes with merge intersect which is completly a waste of time as only the muti-key index should be used and not the single ‘cola’ index.

By: peter

peter — Wed, 29 Aug 2007 07:50:40 +0000

Ryan,

Are you speaking about duplicate indexes or redundant (as vadim is speaking) ?
What problem do you mean ?

By: peter

peter — Wed, 29 Aug 2007 07:49:49 +0000

Vadim,

Actually speaking about selectivity I’d like to see distribution rather than pure selectivity.
If index has 2 values and one of them is in 99% and other in 1% it well may be index is a good idea to look up for second value – status field is typical type of such field.

By: Ryan

Ryan — Wed, 29 Aug 2007 00:06:20 +0000

The main reason I keep around duplicate indexes is because the merge intersect will not use just the first key part of an index. But this also has the disadvantage that it will often use both indexes in the intersect which is a bug in my opinion.

By: Vadim

Vadim — Tue, 28 Aug 2007 17:59:14 +0000

Xaprb,

What about checking selectivity of indexes ?
http://www.mysqlperformanceblog.com/2007/08/28/do-you-always-need-index-on-where-column/

By: Xaprb

Xaprb — Tue, 28 Aug 2007 12:14:56 +0000

For those who want to find duplicate indexes, check out MySQL Toolkit: http://mysqltoolkit.sourceforge.net/