On Mon, 2006-05-01 at 13:37, Philip Hallstrom wrote:
>
> >> I would also read this about mysql's table locking:
> >>
> >> http://dev.mysql.com/doc/refman/4.1/en/table-locking.html
> >>
> >> Specifically, regarding myisam tables:
> >>
> >> "Table locking enables many threads to read from a table at the same time,
> >> but if a thread wants to write to a table, it must first get exclusive
> >> access. During the update, all other threads that want to access this
> >> particular table must wait until the update is done."
> >>
> >> It doesn't take very many writes before this *really* becomes a problem.
> >> We're implementing memcache at work to help with this issue...
> >
> > Yeah, table level locking doesn't really scale well.
>
> Which is ironic since the top of that page says: "For large tables, table
> locking is much better than row locking for most applications..."
>
> Which, just right off the bat, doesn't make much sense... oh well.
Yeah, much of the MySQL documentation used to be that way, what with the
whole "Foreign key relations are best maintained by application code"
kind of stuff it was once full of.
And from reading that page, one can see that InnoDB tables are still
considered to be kind of the "red headed step child" of table handlers
by the mysql crew. Sad, because it's the only table handler they have
than can truly handle any real concurrency of reads and writes mixed
together (it's a true MVCC modeled table handler).
