"mike thomas" <[EMAIL PROTECTED]> writes:
> Greg,
>
> Well, I'm doing like "%stuff%" selects on a single column table
> with 20 million records, so any speed gain would be great. Would
> I be correct in saying that a select of this type will always do
> a table scan?
Pretty much.
> I think I'll go with SCSI and increase the RAM so I can use a
> heap table.
A cheap first step might be to go with a couple of decent 7200 rpm,
ATA100 (or whatever the hell they're calling themsevles this week)
disks and RAID0 them.
Striping Good.
Also, make sure your IDE is spiffed up to the max. Do an:
hdparm /dev/hda (or whatever).
Make sure it's using DMA, unmasked IRQ, 32 bit i/o and, a multcount of
16. Benchmark your drive before and after, with:
hdparm -t /dev/hda
You should see >10MB per second after tuning up.
However, I can't help thinking for your application There Must Be A
Better Way. Do you really need to do substring matching all the time?
Can you pre-build an intermediate results set that can be optimally
queried?
Dave.
--
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star http://www.deep-purple.com
Apache, mod_perl, MySQL, Sybase hired gun for, well, hire
-----------------------------------------------------------------
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
