Re: Using <=> in WHERE vs HAVING clause

[EMAIL PROTECTED] wrote: > > > This is what I wound up going with: > > > > > > SELECT b.id, > > > if(a.a <=> b.a, NULL, b.a), > > > if(a.b <=> b.b, NULL, b.b), > > > if(a.c <=> b.c, NULL, b.c), > > > (NOT (a.a <=> b.a) AND > > > (a.b <=>

Re: Using <=> in WHERE vs HAVING clause

Rene Churchill <[EMAIL PROTECTED]> wrote on 02/22/2005 04:23:47 PM: > [EMAIL PROTECTED] wrote: > > Rene Churchill <[EMAIL PROTECTED]> wrote on 02/22/2005 03:39:05 PM: > > > Hi Shawn, > > > > > > This is what I wound up going with: > > > > > > SELECT b.id, > > > if(a.a <=> b.a, NULL,

Re: Using <=> in WHERE vs HAVING clause

Rene Churchill <[EMAIL PROTECTED]> wrote on 02/22/2005 09:21:29 AM: > Good evening folks, I'm seeing some odd behavior in MySQL 4.0.21 > running on Mac OS X 10.3.7 > > I'm trying to compare two identical tables and find the rows > that are new/modified. I can't use a timestamp column because > t

Re: using IN()

> Put the 60K ints into a temporary table. Next join against this temporary > table. This join forces the optimizer to translate the range into an > eq_ref-one of the fastest type joins. He could also simply use a join to the ID table, provided that the 6 IDs are SELECTable in the current data

RE: using IN()

Although parentUserId is indexed, the fact that you're using an IN list turns the query into a range. IN lists are fast but at certain levels such as yours it is not. The reasons are listed below: The query parser must allocate memory for every string in the list and convert it into an int. So you

Re: using IN() clause

On Wed, 17 Nov 2004 21:02:27 -0800 (PST), Mitul Bhammar <[EMAIL PROTECTED]> wrote: > The query is running fine for now. I wanted to know > how MySQL interprets and executes this query and can > it have problems in future?? Read about MySQL's query optimization here: