You may even want to split the query into pieces and let the application logic handle the resultsets. I had to do this with a long running query that produced 100 records for export (4+ minutes in a web environment). By splitting the 5 table join into 3 queries and application based arrays, I reduced the run time to about 10 seconds with 50x the output.
Bastien
From: Eddie Peloke <peloke@xxxxxxxxx> Reply-To: Eddie Peloke <peloke@xxxxxxxxx> To: php-db@xxxxxxxxxxxxx Subject: mysql query plan Date: Wed, 13 Apr 2005 15:42:41 -0400
Hello,
We are working to optimize a few queries. When we run the query with Explain, it appears that the query optimizer is not using one of the tables index and doing a full table scan while it appears to use other tables' indices properly. We then remove the table with the full scan, run again with Explain and now the optimizer seems to ignore the index of one of the other tables when it correctly used that table's index before in the previous run. Anyone have some good insight into how the optimizer picks it's query plan? It seems to pick one table and ignore the index for some reason.
Thanks!
-- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
-- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
