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
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:
myisamchk --quick --check-only-changed --sort-index --analyze
Maybe I'm missing something
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
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 your
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
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
