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 improve
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 whe
Hi!
> "Jeremy" == Jeremy Zawodny <[EMAIL PROTECTED]> writes:
Jeremy> On Fri, May 17, 2002 at 11:41:49AM +0300, Michael Widenius wrote:
Jeremy> [snip]
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
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
> tab
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
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 i
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 databas
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 ISA
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 t
> >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
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 (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
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 p
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.
Here
14 matches
Mail list logo
