Alexander Barkov wrote:
Héctor,
Changing various buffer sizes can improve performance significantly,
with key_buffer_size as the first thing to tune.
Also, make sure you are using not debugging version of the server.
Please also take a look in this section of the documentation
for details:
htt
Héctor,
Changing various buffer sizes can improve performance significantly,
with key_buffer_size as the first thing to tune.
Also, make sure you are using not debugging version of the server.
Please also take a look in this section of the documentation
for details:
http://www.mysql.com/doc/en/
Hi guys!
Ok, I'm closer to beat Rushmore (VFP optimizer) now!
After some reading about MySQL optimization techniques,
here is the summary of what I've done:
1. Add a compound index to the table
2. Use EXPLAIN to check out the query (with GROUP BY on multiple fields)
3. Create the summary table
And
Mojtaba Faridzad wrote:
BUT my experience: try to change the logic of your report not to retrieve
large number of records. user LIMIT to create the reports page by page. this
is the best and even better for the user.
Ok thanks, but how exactly do I change-the-logic of this query:
mysql> select te
Chris wrote:
Hmm
It's just occured to me that you're basically copying and entire table from
one place to another. If I recall correctly, FoxPro cheats somewhat in this
situation - it just copies the concerned files!
Which table type are you using (something I should have asked in the
begi
etter for the user.
good luck
- Original Message -
From: "Matt W" <[EMAIL PROTECTED]>
To: "Héctor Villafuerte D." <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, October 24, 2003 3:00 PM
Subject: Re: Really slow query (compared with Visual Fo
al Message -
From: "Héctor Villafuerte D."
Sent: Friday, October 24, 2003 12:10 PM
Subject: Really slow query (compared with Visual FoxPro)
> Hi all,
> I'm migrating from Visual FoxPro (I'm a newbie).
> On a daily basis I need to run this query on a table with a little
mo
As you are selecting all records (no where clause), it will scan the whole table every
time, I believe...
does anyone know if he added the other columns to his index, or had 4 seperate indexes
(one per column) would they be used in this operation?
>
> Ok, I've found the optimization chapter i
Dan Greene wrote:
Indexes are your friend. Perhaps your best friend (as far as databases go)
---
To give light on your question... you can index any field... if the entries are
distinct, it's called a 'unique index' which are the best kind to use. Otherwise you
have
u/Quick_Ref/MySQL_QuickRef.pdf (MySQL Quick
Reference Card)
Related links
http://dmoz.org/Computers/Software/Databases/MySQL/Tutorials/
> -Original Message-
> From: "Héctor Villafuerte D." [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 24, 2003 1:40 PM
> To: [E
Hi!
One thing that you have to remember is that FoxPro will always index
some fields, while MySQL
will only ever index the primary key field automatically.
Indexes can be on fields that are distinct or not distinct. The only
difference that exists is
the nature of the index, which is one of tho
Chris Nolan wrote:
Hi!
Given VFP's internals (I have to support FoxPro 2.6 apps, oh the pain
of it all!),
MySQL should be capable of much better performance, considering the
only thing FoxPro has in terms of a possible advantage is Rushmore.
Which indexes do you have on the tables in the query?
Hi!
Given VFP's internals (I have to support FoxPro 2.6 apps, oh the pain of
it all!),
MySQL should be capable of much better performance, considering the
only thing FoxPro has in terms of a possible advantage is Rushmore.
Which indexes do you have on the tables in the query?
Regards,
Chris
H
Hi all,
I'm migrating from Visual FoxPro (I'm a newbie).
On a daily basis I need to run this query on a table with a little more
than
5 million records.
+ MS Visual FoxPro 6.0
select tel, telefb, rutaentran, rutasalien, sum(minutos) as minutos from
traf_oper
group by 1, 2, 3, 4 into table ope
14 matches
Mail list logo
