Your original query (implicit INNER JOINs):
SELECT teu.name, eca.owner_id, ece.value
FROM typed_enterprise_unit teu,
e_contact_association eca,
e_contact_entry ece
WHERE teu.unit_id=eca.owner_id
and eca.entry_id=ece.entry_id
and eca.type_id=68
and (teu.type_path like '%/66/%' or teu.type_id=66)
ORDER BYeca.owner_id
LIMIT 22;
The same query reformatted to demonstrate explicit INNER JOINS
SELECT teu.name
, eca.owner_id
, ece.value
FROM typed_enterprise_unit teu
INNER JOIN e_contact_association eca
ON teu.unit_id=eca.owner_id
INNER JOIN e_contact_entry ece
ON eca.entry_id=ece.entry_id
WHERE eca.type_id=68
AND (teu.type_path like '%/66/%' or teu.type_id=66)
ORDER BYeca.owner_id
LIMIT 22;
I have two immediate suggestions.
1) If you had not attached your information but included it in
your message as text, you would have probably already received an answer.
Next time, please inline your information. Please don't use an attachment
as many people WILL NOT OPEN THEM unless they know you.
2) Be very, very careful when you use a comma delimited list of
tables to imply INNER JOIN that you actually include the necessary join
conditions in your WHERE clause. You did do that this time. However, it is
a well known hazard of that particular query format that those terms can
be accidentally omitted and you can very easily wind up with an
unintentional Cartesian product of your tables.
The explain from your query (extracted from your attachment and included
below) tells me exactly why your query takes so long (heavily trimmed to
avoid excessive message wrapping).
+--+---+--++-++-+--+
|id|select_type|table |type|possible_keys|key | | Extra|
+--+---+--++-++-+--+
| 1| PRIMARY |eca |ALL |NULL |NULL| | Using where; Using
temporary; Using filesort |
| 1| PRIMARY |ece |ALL |NULL |NULL| | Using where|
| 1| PRIMARY ||ALL |NULL |NULL| | Using where|
| 2| DERIVED |tp|ALL |NULL |NULL| ||
| 2| DERIVED |eu|ALL |NULL |NULL| | Using where|
+--+---+--++-++-++
Look at the column "possible_keys". Every entry is NULL. That means that
you have no indexes on your tables that could have been used to respond to
this query. This worries me as tables that are involved in relationships
with other tables should at a MINIMUM contain a primary key. Your slow
performance is due to the fact that the query engine had to perform
complete table scans of all tables involved in this query.
May I strongly suggest some reading for you. If you don't understand any
part of it, come back to the list with your questions and we can help
explain it in other ways.
These articles describe ways to implement indexes(keys) in your database
to speed up your queries.
http://dev.mysql.com/doc/mysql/en/CREATE_INDEX.html
http://dev.mysql.com/doc/mysql/en/ALTER_TABLE.html
http://dev.mysql.com/doc/mysql/en/CREATE_TABLE.html
This article describes how to interpret the output of the EXPLAIN command
http://dev.mysql.com/doc/mysql/en/EXPLAIN.html
These articles help to explain how queries are helped by indexes
http://dev.mysql.com/doc/mysql/en/MySQL_indexes.html
http://dev.mysql.com/doc/mysql/en/SELECT_speed.html
There are also MANY articles on the web about query optimization and index
usage. Use your favorite search engine to help you find them. Nearly all
of the principles and techniques that work for the other database engines
(Oracle, MS SQL Server, Informix, etc) will also work for your queries
with MySQL so don't necessarily limit yourself to just MySQL articles.
To solve your speed problem, you need to create an appropriate set of
keys(indexes) on your tables.
Respectfully,
Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine
"Elim Qiu" <[EMAIL PROTECTED]> wrote on 11/18/2004 07:44:01 PM:
> Dear list,
>
> i have some small tables but for some reason the mysql took very long to
> find the results. my query looks
> like below and mysql'e explain is attached for better format. Thanks for
> your help!
>
> select teu.name, eca.owner_id, ece.value
>
> fromtyped_enterprise_unit teu,
> e_contact_association eca,
> e_contact_entry ece
>
> where teu.unit_id=eca.owner_id and eca.entry_id=ece.entry_id and
> eca.type_id=68 and (teu.type_path like '%/66/%' or
teu.type_id=66)
> and eca.owner_id > 45
>
> order by eca.owner_id limit 50;
> [attachment "need_help_query.txt" deleted by Shawn Green/Unimin] No
> virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.289 / Virus Database: 265.3.1 - Release Date: 11/15/2004
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:http://lists.mysql.com/[EMA