Comments on: MySQL not being able to utilize a compound index?

By: Log Buffer #146: a Carnival of the Vanities for DBAs | Pythian Group Blog

Log Buffer #146: a Carnival of the Vanities for DBAs | Pythian Group Blog — Fri, 15 May 2009 17:01:31 +0000

[...] code.openark.org, Shlomi Noach writes It seems like MySQL is unable to utilize a compound index when evaluating a plan for a query with a range condition. I’m looking for an explanation. I’ll [...]

By: Xaprb

Xaprb — Sat, 09 May 2009 20:51:51 +0000

Shlomi, as others said — this is just an optimizer weakness at the moment. Peter posted on this a while ago, too: http://www.mysqlperformanceblog.com/2008/04/04/multi-column-in-clause-unexpected-mysql-issue/

By: shlomi

shlomi — Sat, 09 May 2009 10:40:03 +0000

@Harrison,

I agree. Thanks for the reference!

By: shlomi

shlomi — Fri, 08 May 2009 19:00:44 +0000

@Shantanu,

Thanks,
1. Haven’t tried this with 5.1
2. I do
3. Unlimited (killed query after realizing it was running for a few minutes)

By: Harrison Fisk

Harrison Fisk — Fri, 08 May 2009 14:22:39 +0000

The query isn’t a subquery, however for some reason that is where the docs mentions the restriction about row operators. I suspect it was because the row operators were added at the same time as subqueries.

Really, the restriction should be put somewhere else in the documentation, such as the index section or even where row operators are mentioned in the docs.

By: Shantanu Oak

Shantanu Oak — Fri, 08 May 2009 09:37:25 +0000

1) Have you tried it on 5.1 version of MySQL?
2) Do you get the same explain plan with and without “limit” ?
3) What is the actual time that it took to return the results?

By: shlomi

shlomi — Fri, 08 May 2009 03:23:42 +0000

@Harrison, @Dean

I don’t think this query can be categorized as “subquery” in any way, or else the optimizer is very wrong.
Do you find that there’s a “sub” here?

By: shlomi

shlomi — Fri, 08 May 2009 03:17:35 +0000

@Matthew,

This doesn’t really change much – you just get a full index scan instead of a full table scan. If I need to get an entire row, I get no advantage. Thanks!

By: Roland Bouman

Roland Bouman — Fri, 08 May 2009 00:54:05 +0000

darn…something is not well with literal <

me tries again….

(a,b) < (x,y) is equivalent to:

CASE WHEN a > x THEN FALSE WHEN a < x THEN TRUE ELSE CASE WHEN b < y THEN TRUE ELSE FALSE END END

By: Roland Bouman

Roland Bouman — Fri, 08 May 2009 00:50:23 +0000

Hi Justin,

the syntax (a,b) < (x,y)

means:

CASE
WHEN a > x THEN FALSE
WHEN a = x THEN
CASE
WHEN b < y THEN TRUE
ELSE FALSE
END
END