Hi,
I am having to write queries that contain operators such as MOD and
DIV in addition to other normal arithmetic operators to add, multiply,
divide, etc. I am also using MAX(), MIN() in the same queries.
Actually, I am using INSERT ... SELECT MAX() * X ... FROM TABLE idiom
to calculate the
Hi,
I use MySQL for years with very much respect of it's stability and
performance.
But in these years one of my servers has grown to several hundreds of
databases with approximately 50 tables in each of the databases.
Some of these database have tables containing more than a million
At 05:32 PM 6/22/2005, you wrote:
Hi,
I use MySQL for years with very much respect of it's stability and
performance.
But in these years one of my servers has grown to several hundreds of
databases with approximately 50 tables in each of the databases.
Some of these database have tables
hi,
you didn't speakabout your tuning work on the databases with only one machine.
Have you done such work with the indexation part for best performance ?
I can tell you that several databases with about 40 Go for all is not huge.
but if you want look at some linux clustering solutions like
A table (Table1) with the relevant indices (e.g.
Field1Idx, Field2Idx) exists. Running a query like:
Select * from table1 where Field1Idx Like 'Value%'
returns result in expected timing scale, so does the
query:
Select * from table1 where Field2Idx Like 'Value%'
The problem (very slow) occurs
Thanks, but this is not what we expected. This means
to change the SQL command in the application. Our
understanding from the manual and other relational DBs
is that, it's suffice for existence of an index on the
field in the criteria (where clause) to run at optimal
speed.
regards
---
Thanks, but this is not what we expected. This means
to change the SQL command in the application. Our
understanding from the manual and other relational DBs
is that, it's suffice for existence of an index on the
field in the criteria (where clause) to run at optimal
speed.
You'll
Yes, you need to change your query for optimal speed. Prior to 5.0.0, mysql
chooses the best index to use, one per table. Your indexes don't help for
this query, because no one index does the job. Why? Because you are
selecting on one column OR another column. If you are using at least
someone tell me what the performance implications are for each
approach? Is the ENUM datatype effectively doing the same thing behind
the scenes (that is, creating some hidden table somewhere and storing an
integer in the actual table)? Will select performance be equivalent
with both approaches
)? Will select performance be equivalent
with both approaches - that is, would
SELECT name FROM person WHERE eyecolor = 'blue' AND haircolor = 'red'
where eyecolor and haircolor are both ENUM fields be equivalent in
performance to a non-normalized table using the varchar datatype, or
would it be equivalent
Hi!
I have a very simple query
SELECT a, b FROM t ORDER BY a, b
I also have an index on t(a)
I have run ANALYZE
Also the number of repetitions of values of a in t is very low.
My view is that the execution should require little temporary space and
little time, something like:
for each
Tim Ward
Brett Ward Limited - www.brettward.co.uk
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 12 July 2002 11:17
To: Tim Ward
Subject: Re: RE: SELECT performance
Your message cannot be posted because it appears to be either spam or
simply
What would you expect?
You ask for the whole file, and then ask
that it be sorted by two fields.
How do you expect this to happen without a temp file?
Tiago Antao wrote:
Hi!
I have a very simple query
SELECT a, b FROM t ORDER BY a, b
I also have an index on t(a)
I have run ANALYZE
Also
On Fri, Feb 15, 2002 at 04:00:11PM +0100, Antoine wrote:
Hello,
Well, for my project at work, I've done some small benchmarking of
different table types for relatively small sizes (some tens or
hundreds of thousands rows - small enough so that key buffer size
and other memory factors
Hi,
At first thanks for the answer. I was wondering if my mail was precise enough.
Your results could have a lot to do with the fact that HEAP tables
used hashed indexes rather than the B-Tree indexes of MyISAM. The set
No, I've really used queries that take advantage of the hash indexes :
Hello,
Well, for my project at work, I've done some small benchmarking
of different table types for relatively small sizes (some tens
or hundreds of thousands rows - small enough so that key buffer size
and other memory factors should not limit performance) and lots of
very simple operations. I
Hi.
I am not sure what you compare against, because the description of the
second test script is not clear to me in the given context.
Anyhow, the difference probably comes from the fact, that MySQL has to
use indexes to find the row which matches to the id and has to access
about log(65000) =~
Hi,
I am trying to benchmark mysql's performance for fetching a random record.
To do so, I have setup the following configuration: Linux, 14 2G tables,
each populated with 65000 records of fixed 32k size, type mediumblob. My
test randomly generates a table/id pair and selects the record. I
18 matches
Mail list logo
