I concur.
The SELECT time is going to resemble something like:
K_1 * F_1(number_of_records_in_database) + K_2 *
F_2(number_of_records_selected)
If the indices are effective, F_1 = log(N), but if the indices are not
effective, F_1 = N.
One thing you may want to try to narrow down the problem is
On Thu, Sep 4, 2008 at 10:38 AM, mos <[EMAIL PROTECTED]> wrote
Jim,
The problem is likely your index is not defined properly. Use an "Explain"
in front of the query to see if it can use just one index from each table.
I would try building a compound index on
Products: (RecordReference, FeedId)
Jim,
I've re-posted your message to the list so others can join in the
fray. :)
Mike
At 10:50 AM 9/4/2008, you wrote:
Hi Mike,
I do believe we have done the indexing properly. Please advise if we can
make any adjustments. Here is the output from the explain statements;
16634be.png
>-Original Message-
>From: Brent Baisley [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, September 03, 2008 5:35 PM
>To: Jim Leavitt
>Cc: mysql@lists.mysql.com
>Subject: Re: Large Query Question.
>
>That's a lot of data to return, make sure you factor in data loa
It's highly unlikely hardware upgrades are needed unless you're on a really
underpowered machine. How similar are the queries on the other machines?
The "limit" clause won't reduce the time taken to do the join and grouping,
it will only reduce the amount of output.
Also, I assumeyou have indexes
At 02:49 PM 9/3/2008, Jim Leavitt wrote:
Hi Mike,
Yes sometimes, the application is an online book selection tool with
about 1 million titles in it. Now the queries which return 100,000 rows
would be something like returning all titles from a given publisher. Most
of the common searches are
On Wed, Sep 3, 2008 at 1:05 PM, Jim Leavitt <[EMAIL PROTECTED]> wrote:
>
> We are having trouble with certain queries which are returning anywhere
> from 10 - 30 rows. Total query time is taking approx 1 - 2 mins
> depending on load. Is there anything in our conf file which could improve
@lists.mysql.com
Subject: Re: Large Query Question.
That's a lot of data to return, make sure you factor in data load and
transfer time. You may try breaking your query into smaller parts and
recombining the results in a scripting language. If you are searching
on a range (i.e. date range), brea
That's a lot of data to return, make sure you factor in data load and
transfer time. You may try breaking your query into smaller parts and
recombining the results in a scripting language. If you are searching
on a range (i.e. date range), break the range into smaller parts and
run multiple queries
What are the queries? Are they straight forward selects or joins? Are the
columns you select from indexed and are the indexes up-to-date?
On Wed, Sep 3, 2008 at 12:05 PM, Jim Leavitt <[EMAIL PROTECTED]> wrote:
> Greetings List,
>
> We have a medium-large size database application which we are t
Jim,
Retrieving 100,000 rows will always take some time. Do you really
need to return that many rows? Are you selecting just the columns you need?
What are the slow queries?
Mike
At 12:05 PM 9/3/2008, Jim Leavitt wrote:
Greetings List,
We have a medium-large size database application
Greetings List,
We have a medium-large size database application which we are trying
to optimize and I have a few questions.
Server Specs
1 Dual Core 2.6 Ghz
2GB Ram
Database Specs
51 Tables
Min 10 rows, Max 100 rows
Total size approx 2GB
My.cnf
[mysqld]
set-variable=local-infile=0
12 matches
Mail list logo
