Re: [Nolug] MySQL Help?

From: Ron Johnson <ron.l.johnson_at_cox.net>
Date: Sat, 29 May 2004 17:09:23 -0500
Message-Id: <1085868563.29540.6.camel@haggis.homelan>

On Sat, 2004-05-29 at 14:14 -0400, Mark A. Hershberger wrote:
> Ron Johnson <ron.l.johnson@cox.net> writes:
>
> > What do the indexes, if any, on tblData look like?
>
> PRIMARY KEY (`id`),
> KEY `idusername` (`id`,`username`),
> KEY `zip` (`zip`(5)),
> KEY `apptypezip` (`zip`(5),`apptype`(7)),
> KEY `username_idx` (`username`(10))
>
> on zipDistances
>
> KEY `origdist` (`origin`,`distance`),
> KEY `zip` (`zip_distant`)

Since the OP didn't have the full SELECT statement, I
can't help much more, since you only mentioned the
1st predicate.

Besides, while I'm a DBA, I don't know the internals
of MySQL, to tell you how *it* would act in a given
situation. Sorry.

> > Also, remember that DISTINCT adds computational and disk
> > overhead to the operation, since it has to *sort* all the
> > records in the table, in order to eliminate duplicates.
>
> Yes, but it is still /far/ faster than the really huge "zip in" that
> we were using before.

WHERE zip in (SELECT zip from zipDistances...) ?

I should hope so! That's what INNER JOIN is for.

> And, it shouldn't lock the table, right?

Well, I've heard that table locking has traditionally
been MySQL's favorite kind of locking, from it's roots
where it was weighted towards read-heavy environments.

-- 
Ron Johnson <ron.l.johnson@cox.net>
___________________
Nolug mailing list
nolug@nolug.org
Received on 05/29/04

This archive was generated by hypermail 2.2.0 : 12/19/08 EST