Is that the only table in your MySQL installation?
MyISAM primary keys are put in a b-tree index, which is cached by MySQL in memory in the key_buffer_size parameter. What is it set to on your system (the my.cnf file, probably in /etc or /var)?
The second time you run it, the index is definately in memory, which is why it is so fast.
Perhaps the OS is swapping MySQL pages out to disk, or perhaps there is not enough memory allocated to the key-buffer to keep the index in memory.
The more frequently you access data, the more likely it is to be cached by the OS or the database. Not sure what is running on your system or how it is configured, but the amount of memory you have looks a bit light. Databases are much faster with more memory.
David.
Jacob Elder wrote:
Here's my table:
CREATE TABLE 'data' ( 'junk' char(10) NOT NULL default '', PRIMARY KEY ('junk') ) TYPE=MyISAM;
There are about 1.7 million 10-character long strings. A query like this one takes about 5 seconds:
SELECT junk FROM data WHERE junk='xxxxxxxxxx';
Subsequent queries for the same string return right away.
This is MySQL 4.0.18-5 from Debian testing on a dual Xeon 1.8Ghz with 512 ram and hardware raid5. Load from other services on this machine is minimal. There is no other MySQL traffic at this time.
Is it normal for this to take so long? Grepping against a flat text file representing my data takes a far less than a second. Any thoughts, folks?
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]