Following up to my own question. Some more information.
SLOW: Create unique compound index on a table, do a query.
FAST: Create same index, only non-unique, do a query.
FAST: Do slow method, but ANALYZE TABLE before doing query.
It looks like the key-distribution information that's stored by
On Friday 28 March 2003 04:39, harlan at artselect dot com wrote:
When querying a largish (370,000 rows) table, a unique compound index
on its three int columns performs slower (as slow as no index at all)
than when I use the same index created without the unique keyword.
I've repeated it
Hi,
When querying a largish (370,000 rows) table, a unique compound index
on its three int columns performs slower (as slow as no index at all)
than when I use the same index created without the unique keyword.
I've repeated it dozens of times: Create the index unique, and it's
slow, create it
