Comments on: When the subselect runs faster

By: Istvan Podor

Istvan Podor — Tue, 20 Apr 2010 06:03:51 +0000

Nikolay:

If you would give me the explain I could give an exact answer. Now it’s looks like because the joins are slow/slower in the subquery. As I mentioned in the post, the subquery will be executed for each result of the main query. So in this case each query like this means 20 joins

By: Nikolay Mihaylov

Nikolay Mihaylov — Sat, 17 Apr 2010 10:41:49 +0000

Why not something with union / join?

select * from table where id in (
select id from table where col1=’a’
union
select id from table where col1=’b’
)ORDER BY id DESC LIMIT 20

or even:

select t1.* from table t1, (
select id from table where col1=’a’
union
select id from table where col1=’b’
) t2
where t1.id = t2.id
ORDER BY id DESC LIMIT 20

By: zhangll

zhangll — Mon, 29 Mar 2010 05:44:12 +0000

Nice!

By: varzosu

varzosu — Thu, 25 Mar 2010 22:45:53 +0000

I suggest to also run the queries in a different order, to make sure that the caching of blocks by the kernel does not happen in favor or the second query.
The most useful would be the have a col1,id index so definitely the index would be used by default.

By: jpgerek

jpgerek — Tue, 23 Mar 2010 09:29:03 +0000

I think that the real problem is having an index in col1, it’s not optimal at all having and index in a field with just 9 different possible values, and index is as efficient as its cardinality. I would try removing the index in col1, moreover you would save memory and the index creation when inserting rows.

By: Patrick Casey

Patrick Casey — Mon, 22 Mar 2010 01:05:15 +0000

Seems like this is really just a workaround for a weakness in the optimizer. Properly handling limit clauses in the optimizer is definitely something I’d like to see tackled.

By: peter

peter — Sat, 20 Mar 2010 04:19:12 +0000

zerkms,

Yes estimation may give different value. Regarding PRIMARY KEY this is because MySQL does primary key lookups for rows as it retrieves them in the order and after fetching row by primary key checks if it matches WHERE clause.

By: zerkms

zerkms — Thu, 18 Mar 2010 16:50:40 +0000

ah, about first question: seems like the optimizer get a projected number of possible affected index records aproximately due to it’s measured before real query was executed

By: zerkms

zerkms — Thu, 18 Mar 2010 16:48:06 +0000

why it is differen number of rows in cases (606920 vs 765105)?
and why it is PRIMARY as key for DEPENDENT SUBQUERY in second case?