In the end, I had to use the select-from-a-select method to get the variables to calculate correctly as I’m doing a cross product with a calendar table which messes the evaluation time up completely. but at least I now have a working query!

set @num=0, @type := ”;
select * from fruits
where (@num := if(type = @type, @num + 1, 1))
and (@type := type)
and (@num <= 2);
Empty set (0.00 sec)

select @num, @type;
+——+——–+
| @num | @type |
+——+——–+
| 9 | cherry |
+——+——–+

On MySQL 5.1.41-3ubuntu12.10 the result is:

select @num, @type;
+——+——–+
| @num | @type |
+——+——–+
| 2 | cherry |
+——+——–+

I don't know how the heck you got 9 there.
Your article is excellent though.

I found your blog when searching for an odd side-effect of using user variables in (rather simple) queries -they get very slow.

As way of example, we join a couple of tables, one of them with about a million recs the other one < 300 recs.

Here is the original version:

set @version = '100952';
select j.wo, t.wo from
(
select distinct wo from t1.details where version = @version and reg_id ‘foo’
) t
right join table2.wo2 j on locate(j.wo,t.wo);

This takes about 12 secs, now, if I get rid of the set @version…

select j.wo, t.wo from
(
select distinct wo from t1.details where version = ’100952′ and reg_id ‘foo’
) t
right join table2.wo2 j on locate(j.wo,t.wo);
This takes < 1 sec!

These are InnoDBs on a 5.1 server on an XP SP3 machine 2GHz 2GB that pretty much only hosts the MySQL server.

I can repeat these results at anytime. On more complex queries I get similar improvements when getting rid of the user vars. What is it with these things?
Loved the your post btw. Thanks!