Comments on: Advanced MySQL user variable techniques

By: Josh Strike

Josh Strike — Tue, 03 Jun 2008 05:36:01 +0000

Thanks. I tried that, actually…but something really bizarre seems to happen with the ORDER BY — at least the way I’m running it. Say I’m ordering the example by type in a subquery; The results come out in the correct order, but @num is still being incremented according to the original order. I’m thinking maybe I need to somehow have those variables eval in the order clause rather than the where…if that’s somehow possible…

By: Xaprb

Xaprb — Tue, 03 Jun 2008 03:26:25 +0000

You can do things in “derived tables” and order them inside that table; then join against the table you want to update. MySQL will (probably, sometimes) put the derived table first in the join order.

To be clear:

update foo inner join (select …. [with variable magic] order by bar) as x using(somecol) set foo.y = x.z

By: Josh Strike

Josh Strike — Tue, 03 Jun 2008 03:00:43 +0000

I should have said… can’t order a multi-table update.
Actually, I’m still banging my head against that one…without which this method won’t work…Any ideas for how to force order in that case so this could work?

By: Josh Strike

Josh Strike — Tue, 03 Jun 2008 02:11:33 +0000

First of all, brilliant; I don’t know how you reached this hack but it’s great. Now we can do a massive recursive update in one query instead of maybe a few hundred queries. AWESOME.

The biggest problem, of course, is the ordering thing, and the fact that you can’t order an update query… so it has to be really carefully constructed.

I noticed too that there were some issues, at least in my implementation, where @type would be set at the same time as @num, which could result in some weird behaviour.

Rather than putting @type:=type IS NOT NULL in a separate where clause, doing this seems to help ensure the execution order:

select *, @num
from fruits
where
(@num := if(type = @type, @num 1, IF(@type := type,1,1))) is not null
and (@num

By: Xaprb

Xaprb — Sat, 19 Apr 2008 15:20:41 +0000

Dan, yes we’re depending on undocumented behavior.

By: Dan

Dan — Sat, 19 Apr 2008 14:05:37 +0000

Excellent investigative work, thank you.

One issue that concerns me is that within the call to GREATEST(), the order of evaluation of each argument is assumed to be left to right. So that in

greatest(
@num := if(@type = type, @num 1, 1),
least(0, length(@type := type)))

The comparison @type = type is done before the new assignment, within length(), within least() of @type := type. Without this order, this would not work.

I could not find anything in the mysql reference manual that confirms that function parameters are evaluated left to right.

Clearly this works, but are we depending on undocumented behaviour subject to change or have I missed something?

Thanks

By: Xaprb

Xaprb — Thu, 29 Nov 2007 11:44:46 +0000

See http://dev.mysql.com/doc/en/user-variables.html

By: Nwfrg

Nwfrg — Thu, 29 Nov 2007 04:55:24 +0000

I looked around a bit and I can’t find anything about the colon equals (:=) you use in your example.

What the difference between…

set @num := 0

and

set @num = 0

By: Web Developer Blog » Blog Archive » MySQL User Variables

Web Developer Blog » Blog Archive » MySQL User Variables — Tue, 22 May 2007 20:42:52 +0000

[…] http://www.xaprb.com/blog/2006/12/15/advanced-mysql-user-variable-techniques/ […]

By: Ernest Leitch

Ernest Leitch — Fri, 04 May 2007 18:55:13 +0000

I found your site while looking for user type variables in HAVING statements because I had a problem trying to use them in a having statement.

It wasn’t the silver bullet solution I was looking for, but it lead me to figure out where to put my variable evaluations so it would bring back the right values.

I’m glad you figured this out because I wouldn’t have thought to hide the variables in and IS NOT NULL statement. I placed them in a LEFT JOIN and they started evaluation correctly and now it’s the sweetest query I’ve ever written.