My innodb_buffer_pool_size is:
innodb_buffer_pool_size | 8388608
That looks like 8MB... that sounds small if I have a DB with over 1M
rows to process. No?
Yes, that's extremely small. I'd go for at least 256M, and maybe 512M
if your machine will primarily be doing mysql duties.
On Saturday 25 November 2006 17:54, John Kopanas wrote:
The following query takes over 6 seconds:
SELECT * FROM purchased_services WHERE (purchased_services.company_id =
535263)
What does EXPLAIN say about that query?
Have you done an optimize recently?
--
Scanned by iCritical.
--
MySQL
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
In the last episode (Nov 26), John Kopanas said:
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;
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]
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 should and only does return 1-6 rows depending on the id.
Never more then that. Here are the
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...
I tried the same tests with the database replicated in a MyISAM
engine. The count was instantaneous but the following still took
3-6seconds:
SELECT * FROM purchased_services WHERE (purchased_services.company_id = 535263)
The following though was instantaneous:
SELECT * FROM purchased_services
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
In the last episode (Nov 25), John Kopanas said:
Sorry about these questions. I am used to working with DBs with less
then 10K rows and now I am working with tables with over 500K rows
which seems to be changing a lot for me. I was hoping I can get some
people's advice.
I have a
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
13 matches
Mail list logo
