Well, this is a very unique question. How can we force MySQL to IGNORE an
index. Is this so you can test your disk systems data throughput? I am
quite interested in why you need to see the disk activity in order to
understand if it's working or not.
I have concentrated so hard and so long on making sure that it DOES use
indices whenever they are available I am not sure how to answer that
question. I know there is a setting that controls the size of the "key
buffer" perhaps if you tune it to be really small it will force MySQL to
read the indices straight off of the disk (or maybe not, I am not sure).
Have you tried specifying a "wrong" index in your select statement (so as
to force a table scan) with the USE keyword?
Another solution could be to just get rid of the indices. Then ALL lookups
would be table scans. You could replace each primary key with a unique
constraint (not a unique index) to keep out the duplicates.
Or search on a column that is not part of an index.
Another solution could be to restart the server just before each test.
Doing that will ensure that the cache is empty and that any data that needs
to come from disk will do so (including indices). Merely flushing the cache
while running will commit changes to disk but I don't believe that it will
clear the cache.
The excellent people on the MySQL internals discussion may be better
equipped to answer this.
Curiously yours,
Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine
"Leonardo
Francalanci" To: "Mysql" <[EMAIL PROTECTED]>
<[EMAIL PROTECTED] cc:
tel.ie> Fax to:
Subject: R: R: why CPU is high while
disks are idle in a table scan???
06/22/2004 03:55
AM
First: thank you for sparing so much time with me.
> There are 3 major factors determining your performance: 1) the
> speed of the
> CPU, 2) the size if your RAM, and 3) the data transfer speed of
> your disks.
I thought that the size of tables in the db would have made a difference.
>From the analysis you did and from my tests it doesn't look so...
> 5) If your application is smart enough, you can split your data over
> several servers. This would be a SERIOUS performance increase.
In fact I'm writing a jdbc driver in java that I hope will be included
in c-jdbc (http://c-jdbc.objectweb.org/), which is a java database
cluster middleware (check it out, it seems very interesting)
> 2) you can move parts of your data to other disks. Using multiple I/O
> channels should be faster than a single channel.
That is what I am trying right now, but I am having problems because
it seems that there is no disk I/O if I access by index on my tables,
even if I access most of the table data (while with a table scan
disks work as expected).
Does it happen because I have 1Gb of Ram? If yes: I know that this
sounds like a silly question but... How can I "fill" the memory of my
machine so it doesn't cache data? (I can't just remove memory, I don't
have physical access to the machine)
Thank you
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
