Hi!
Luciano == Luciano Barcaro [EMAIL PROTECTED] writes:
Luciano Hi Monty,
Luciano Michael Widenius wrote:
Hi!
Jeremy Is that supposed to happen in 4.0.x? I don't recall having seen a
Jeremy commit that affected the key cache yet.
Sanja has been trying to do improvements to the key
On Fri, May 17, 2002 at 11:41:49AM +0300, Michael Widenius wrote:
[snip]
In a case like this (where so many rows are covered by the index)
it's not self evident that a table scan is not faster than an index
scan.
Especially with many users using the key cache at the same time, a
table
Hi!
Jeremy == Jeremy Zawodny [EMAIL PROTECTED] writes:
Jeremy On Fri, May 17, 2002 at 11:41:49AM +0300, Michael Widenius wrote:
Jeremy [snip]
cut
Jeremy That reminds me. A while back (9 months, maybe), I seem to remember
Jeremy you discussion a re-write of the key cache so that it would
Hi Monty,
Michael Widenius wrote:
Hi!
Jeremy commit that affected the key cache yet.
Sanja has been trying to do improvements to the key cache code, but we
are still not satisfied with this. He just went back to the sub
select code, so we can't just now give a definite answer when we
Hi!
Myk == Myk Melez [EMAIL PROTECTED] writes:
Myk Michael Widenius wrote:
You can check if the index are ok with CHECK TABLE; If this says the
index is ok, they are not corrupted.
Myk Apparently this doesn't work in all cases. CHECK TABLE told me
Myk everything was fine, but dumping
Hi!
Myk == Myk Melez [EMAIL PROTECTED] writes:
Myk Steven Roussey wrote:
Are the tables defined the same on both servers?
Myk Yes, the tables are defined exactly the same.
Is the data the same?
Myk Just about. The data on the working server is a copy of the database on
Myk the
Michael Widenius wrote:
You can check if the index are ok with CHECK TABLE; If this says the
index is ok, they are not corrupted.
Apparently this doesn't work in all cases. CHECK TABLE told me
everything was fine, but dumping the data to a dump file via mysqldump
and then re-importing it
Steven Roussey wrote:
Are the tables defined the same on both servers?
Yes, the tables are defined exactly the same.
Is the data the same?
Just about. The data on the working server is a copy of the database on
the broken server. For previous tests I used a several-weeks-old copy
of the
I haven't found the problem, but I seem to have found the solution. If
I dump the data and re-import it (causing the index files to be
re-created from scratch), the indexes work fine. I think this problem
started when I upgraded from MySQL 3.22.30 to 3.23.44 and converted the
tables from
Steven Roussey wrote:
The corollary to the above quote is that MySQL can not use indexes with
an OR clause at the base level.
MySQL *does* use the index on a different server, though, it just
doesn't use the index on that server. Compare the results of EXPLAIN
queries on the two servers
The corollary to the above quote is that MySQL can not use indexes
with
an OR clause at the base level.
MySQL *does* use the index on a different server, though, it just
doesn't use the index on that server. Compare the results of EXPLAIN
queries on the two servers (after ANALYZE TABLE
I have some more information about the problem. It seems to be caused
by the presence of an OR or IN clause in the WHERE portion of the query.
Without the clause, 2.23.44 uses the appropriate indexes, but with the
clause it does not. 2.23.41 uses the appropriate indexes in both cases.
A search for 'indexes' brings this as the first result:
5.4.3 How MySQL Uses Indexes
http://www.mysql.com/doc/M/y/MySQL_indexes.html
Inside the page:
Any index that doesn't span all AND levels in the WHERE clause is not
used to optimise the query. In other words: To be able to use an index,
a
On Mon, Apr 22, 2002 at 10:26:22PM -0700, Steven Roussey wrote:
Inside the page:
Any index that doesn't span all AND levels in the WHERE clause is not
used to optimise the query. In other words: To be able to use an index,
a prefix of the index must be used in every AND group.
[Note:
14 matches
Mail list logo
