Hi All
At 11:17 PM 6/6/2002 -0700, Jeremy wrote:
> > However, there is the occasional "select" query that requires a good
> > amount of work on the database.
>
>Why? Can it be optimized?
The query is needs about 10 left joins, and requires data from about 12
different tables (some tables have > 50,000 rows). I believe everything is
indexed properly, because the query is very fast when it is run without the
"order by," and "group by" clauses... We are using LIMIT 50, but MySQL
still has to sort through many (>50,000) rows.
> > Is there a smart way to "limit system resources per thread"?
>
>Nope.
I saw section 4.6.3 of the maual ("Limiting user resources"), but was
hoping for some kind of undocumented tweak.
> > I'd much rather have the long-query person wait an extra few seconds
> > than have several short-query people wait. I've tried tuning all
> > the typical parameters, but I don't think the logjam is memory-based
> > (the hard disk doesn't move).
>
>Hmm... Have you tried making the slow query a LOW_PRIORITY one?
I don't think a "select" statements have a "low_priority" flag?? Is there
an alternative? I'd rather not go back and change all the "fast" queries
to "high_priority," and I don't even think that will have much of an
affect, since MySQL only queue's "high_priority" "selects" in front of
"inserts" and "updates."
Thanks Jeremy,
Matt
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
