>
> > Could be just parania. Several time a second is not much. My guess
> > is that you'll be fine. If it gets slower upgrade your hardware or
> > reconfigure your OS or/and FS or/and MySQL. Anyway, my string
> > opinion is that you should split the table. As i said before that
> > we've
> > been doing for years now (keep all blob, text fields in separate
> > tables).
> > For me it is a strict rule by now.
> >
> > Split it!
>
> I'm about to.
>
> But....:)
>
> What it critical for the application is fast selection from all
> fields, including the document field. I have now made a copy of
> the entire database, where I did the split on the copy.
>
> SELECT * FROM main LIMIT 10000,100
> on the original db took approx 28 seconds.
>
> SELECT m.url, ..., FROM main m, doc d WHERE m.url=d.url LIMIT 10000,100
> on the splitted database took 40 secs. (the ... stands for all
> attribute names in main)
>
> So I'm afraid of the loss when the database reaches a million
> rows.
>
> (SELECTS without the document is significantly faster (from 50
> seconds to .2 seconds), but these queries are not that critical
> for the application.)
You're not joining on a character-field, are you? (bad, bad, bad :)
Anyway, if you want to do a select without a real where that limits the
number of records that should be returned then the split up will do you
little good. The strength of a splitup is that you can do the calculations
with the numbers very, very fast and then get the data from the text/blob
records using one numeric primary key.
-S
---------------------------------------------------------------------
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
