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 ANALYZE TABLE is done (and stored) when creating a non-unique index, but not when creating a unique one. Tested in 4.0.12 and 3.23.56. I have a simple test case if needed. (There's way too much data in the test case to present it here.) --Pete On Thu, Mar 27, 2003 at 08:39:41PM -0600, wrote: > 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 non-unique and it's fast. The EXPLAINs look the same > for both. > > Is this to be expected under some circumstances, or do I get to > isolate this messy situation (it's an ugly query) for a bug report? > > MySQL-3.23.55, Linux, MyISAM. > > Thanks, > > --Pete -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
