Thanks a lot for your help.
The query should and only does return 1-6 rows depending on the id.
Never more then that. Here are the comperative EXPLAINs:
mysql EXPLAIN SELECT * FROM purchased_services WHERE id = 1000;
The application is not in production yet but when it will go in
production the server will be considerably faster and have much more
RAM. But before I put the app in production I want to make sure it is
working properly. 500K rows does not sounds like that much in this
day in age. If I
When I did a:
SELECT * FROM purchased_services WHERE company_id = 1000;
It took me 7 seconds. This is driving me crazy!
I am going to have to try this on another computer and see if I am
going to get the same results on another system. Argh...
On 11/26/06, Dan Nelson [EMAIL PROTECTED]
Yes... with FORCE INDEX it still takes 7 seconds.
On 11/26/06, Dan Nelson [EMAIL PROTECTED] wrote:
In the last episode (Nov 26), John Kopanas said:
On 11/26/06, Dan Nelson [EMAIL PROTECTED] wrote:
In the last episode (Nov 26), John Kopanas said:
Thanks a lot for your help.
The query
At 08:31 PM 11/26/2006, John Kopanas wrote:
When I did a:
SELECT * FROM purchased_services WHERE company_id = 1000;
It took me 7 seconds. This is driving me crazy!
I am going to have to try this on another computer and see if I am
going to get the same results on another system. Argh...
If I just SELECT id:
SELECT id FROM purchased_services WHERE (company_id = 1000)
It takes approx 2-2.5s. When I look at the process list it looks like
that it's state seems to always be in sending data...
This is after killing the db and repopulating it again. So what is going on?
On
This kind of timeframe (2 - 2.5 secs) could just be the result of
running on a laptop. You've got a small amount of RAM compared to
many servers, a bit slower processor, and *much* slower hard disk
system than most servers. If your query has to access multiple
records spread out throughout the
