> You know, this might sound strange, but does the performance drop off at
> all if you lose the indices? A table scan of rows 8 bytes wide is going
> to be pretty damn quick. Plus there's a lot less maintenance to do
> without
> indices and no risk of them getting corrupted.
A full table scan is
On 8 Feb 2004, at 20:28, Mark Hazen wrote:
My tables are just 2 INT columns. I have unique indexes on them going
both
ways.
Sounds like you're sorted.
You know, this might sound strange, but does the performance drop off at
all if you lose the indices? A table scan of rows 8 bytes wide is goin
> What's the nature of your query?
>
> If it's using an integer index and that's what your searching on, then
> having
> it physically sorted is a Good Thing. If you're table-scanning your
> main table, you're toast anyway. Finding ways of making that faster is
> the
> way to go, maybe partitioning
On 8 Feb 2004, at 19:37, Mark Hazen wrote:
*snip*
Here's my problem: I've got a bunch of tables with hundreds of
millions of
rows in them. Every night, I delete about couple million rows and
then run
millions of searches on these tables.
What should I worry about more? A sorted index or a da
lto:[EMAIL PROTECTED]
> Sent: Sunday, February 08, 2004 11:46 AM
> To: [EMAIL PROTECTED]
> Subject: myisamchk vs OPTIMIZE TABLE
>
>
> Hi all!
>
> Running 4.0.17.
>
> I hope this isn't a stupid question, but it appears that OPTIMIZE TABLE is
> NOT equivalent to:
>
Hi all!
Running 4.0.17.
I hope this isn't a stupid question, but it appears that OPTIMIZE TABLE is
NOT equivalent to:
myisamchk --quick --check-only-changed --sort-index --analyze
Maybe I'm missing something, but OPTIMIZE TABLE rebuilds both the data file
and the index file (I see a TMD and TMM
