Jacob Elder wrote:
Thanks to everyone who helped me with this. I settled on breaking it down
into area code, exchange and subscriber. This is one of the most generous
lists I've ever had the pleasure of begging for help on.
I don't want to deter you from making the changes above, but it's pretty
Thanks to everyone who helped me with this. I settled on breaking it down
into area code, exchange and subscriber. This is one of the most generous
lists I've ever had the pleasure of begging for help on.
--
Jacob Elder
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mys
;
cc:
05/18/2004 05:02 Fax to:
PM
At 01:22 PM 5/18/2004, you 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='xx';
S
> I hear what you're saying about memory, but I really don't understand why
a
> btree lookup would be so dramatically slow compared to a linear search
with
> grep. Would something other than MyISAM be more appropriate here?
If you feel that a linear search is faster, why not try to let MySQL IGNOR
On Tue 18 May 02004 at 04:53:52PM -0400, [EMAIL PROTECTED] wrote:
>
> Jacob,
>
> Don't worry about storing the leading the zeroes. Just left pad the
> subscriber column to be 4 digits on output and you should be golden. MySQL
> has a function just to generate left-padded numbers:
>
> LPAD(subscr
05/18/2004 04:05 Fax to:
PM
Sorry, the variable is actually "key_buffer_size" (I don't use MyISAM);
I'm not sure what it defaults to, but the typical recommendation is 25%
of your memory.
You can tell if your cache is effective by looking at the key_reads and
key_read_requests (from the MySQL window, type "SHOW STATUS" wi
uld be returned.
...
Create an index and see if your speed increases.
-Original Message-
From: 'Jacob Elder '
To: '''[EMAIL PROTECTED] ' ' '
Sent: 5/18/04 3:05 PM
Subject: Re: Simple table, 1.7 million rows, very slow SELECTs
On Tue 18 May 02004 at 02:4
be stripped off?
>
> -Original Message-
> From: Jacob Elder
> To: Victor Pendleton
> Cc: '[EMAIL PROTECTED] '; ''[EMAIL PROTECTED] ' '
> Sent: 5/18/04 2:11 PM
> Subject: Re: Simple table, 1.7 million rows, very slow SELECTs
>
> On Tu
On Tue 18 May 02004 at 12:26:41PM -0700, David Griffiths wrote:
>
> Is that the only table in your MySQL installation?
Yes, and no one has access to it yet but me.
>
> 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
Subject: Re: Simple table, 1.7 million rows, very slow SELECTs
On Tue 18 May 02004 at 02:03:55PM -0500, Victor Pendleton wrote:
> From this explain plan it appears a full table scan will be done. What
is
> the cardinality of this index?
>
Actually, they are phone numbers. I wasn't sure
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
On Tue 18 May 02004 at 02:03:55PM -0500, Victor Pendleton wrote:
> From this explain plan it appears a full table scan will be done. What is
> the cardinality of this index?
>
Actually, they are phone numbers. I wasn't sure how this list would feel
about this but I am wring a National Do-Not-Call
>From this explain plan it appears a full table scan will be done. What is
the cardinality of this index?
-Original Message-
From: [EMAIL PROTECTED]
To: Victor Pendleton
Cc: '[EMAIL PROTECTED] '
Sent: 5/18/04 1:54 PM
Subject: Re: Simple table, 1.7 million rows, very slow SE
On Tue 18 May 02004 at 01:47:25PM -0500, Victor Pendleton wrote:
> What is the cardinality of the `junk` column? What does an EXPLAIN Plan
> show?
>
mysql> explain select junk from data where junk='xx';
+-+---+---+-+-+--+-+
On Tue 18 May 02004 at 08:49:05PM +0200, Jigal van Hemert wrote:
> > 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='xx';
> >
> > Subsequent queries for the same string return right away.
>
> 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='xx';
>
> Subsequent queries for the same string return right away.
That's because you have the mysql query cache enabled and mysql can return
the an
What is the cardinality of the `junk` column? What does an EXPLAIN Plan
show?
-Original Message-
From: Jacob Elder
To: [EMAIL PROTECTED]
Sent: 5/18/04 1:22 PM
Subject: Simple table, 1.7 million rows, very slow SELECTs
Here's my table:
CREATE TABLE 'data' (
'junk' char(10) NOT NULL de
19 matches
Mail list logo
