UNIQUE and your INDEX overlap and the INDEX is not necessary.
Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine
Thanks for the answer.
I know it is an index... I did not know that an index using 2 columns
will be used when calling a statement that uses only one of tho
"Michael J. Pawlowsky" <[EMAIL PROTECTED]> wrote on 10/28/2005 11:28:42
AM:
>
> When creating an index in phpMySQL I get a warning message about having
> 2 indexes using the same field.
>
> The table is simply a product comment table.
>
> The first index is simply an INDEX on the product_id to
When creating an index in phpMySQL I get a warning message about having
2 indexes using the same field.
The table is simply a product comment table.
The first index is simply an INDEX on the product_id to speed up
displaying them when someone wants to lookup the comments for that product.
The s
Scott Gifford <[EMAIL PROTECTED]> writes:
[...]
> I think I'm going to take a look at the MySQL source and see if
> there's anything I can tweak to get the effect I want. I'll report
> back my results.
The MySQL source looked a bit too complex for casual hacking, but
here's what I ended up doin
"Jigal van Hemert" <[EMAIL PROTECTED]> writes:
> From: "Scott Gifford"
[...]
>> Right, ALL would be a great plan if it weren't for the LIMIT 1.
>
> The LIMIT 1 will be performed *after* the recordset is sorted :-(
Ah, I think that is the piece I was missing.
[...]
>> I'm a little surprised My
From: "Scott Gifford"
> >> Apparently MySQL's optimizer sees that it can use the primary key for
> >> mirealsource_home_supplemental to do the query, but for some reason
> >> decides not to.
> > This is often the case when the query will probably return more than 30%
of
> > the records in that tabl
Thanks for your response, Jigal. More below...
"Jigal van Hemert" <[EMAIL PROTECTED]> writes:
> From: "Scott Gifford"
[...]
>> Apparently MySQL's optimizer sees that it can use the primary key for
>> mirealsource_home_supplemental to do the query, but for some reason
>> decides not to.
>
> Thi
From: "Scott Gifford"
> mysql> explain
> SELECT mirealsource_homes.mls_num,
> mirealsource_homes_supplemental.listdate,
> mirealsource_images.image1,
> mirealsource_homes_stats.detail_views
> FROM mirealsource_homes,
> mirealsou
I'm having a hard time figuring out why a query in my application is
slow. It seems that MySQL is using a filesort where it's not
necessary, and as a result a query that should be taking a fraction of
a second is taking up to 10 seconds.
Essentially, the query is doing a join of 4 tables, two of
On Wed, 20 Nov 2002, Joseph Bueno wrote:
> Fabrizio Nesti wrote:
> >
> > Why this simple query does not use the PRIMARY key (which is oai_ui)?
> >
> > mysql> explain select * from idb_metadata where oai_ui like 'doi:10.1088/0%';
>
> > While this is correctly using it
> > mysql> explain sel
Hi,
>From the manual (http://www.mysql.com/doc/en/MySQL_indexes.html):
Fabrizio Nesti wrote:
> Hello, it may be a simple question, but I can't get to it:
>
> Why this simple query does not use the PRIMARY key (which is oai_ui)?
>
> mysql> explain select * from idb_metadata where oai_ui like '
Hello, it may be a simple question, but I can't get to it:
Why this simple query does not use the PRIMARY key (which is oai_ui)?
mysql> explain select * from idb_metadata where oai_ui like 'doi:10.1088/0%';
+--+--+---+--+-+--+++
|
1 | a | A |
1 | NULL | NULL | |
+---++--+--+-+---+--
---+--++-+
1 row in set (0.00 sec)
2) Why index using in different way when cardinality = 1 and cardinality &g
1 | a | A |
1 | NULL | NULL | |
+---++--+--+-+---+--
---+--++-+
1 row in set (0.00 sec)
2) Why index using in different way when cardinality = 1 and cardinality &g
14 matches
Mail list logo
