I'm looking to make the move to InnoDB, too. All I've heard is positve.
Here's a reply I got on another list:

--------------------
If you have a very busy read/write op database, MyISAM can't handle
it.  It's very efficient for when you have many more reads than
writes, but once you start hitting a balance between the two and
then get some load, MyISAM just locks up.  It's just known.
Table-level locks lead to lengthy delays.

Our experiences with InnoDB have been absolutely terrific.  We've
peaked at 800/inserts/sec on mediocre hardware into multiple complex
tables (large indices, many indices, etc.).  The only problems
we've had is the foreign key vs. alter table issue.  Alter table
wipes out foreign keys, and a lot of the things MySQL does behind
the scenes to make things work use alter table.
--------------------

As Jeremy said, you can always create more space later and you don't have to
worry about Commit/Rollback or AUTOCOMMIT, unless you're using transactions.
I'm assuming you're not, since you're moving from MyISAM.

Thanks,
--jeff

----- Original Message -----
From: "Jeremy Zawodny" <[EMAIL PROTECTED]>
To: "Steve Rapaport" <[EMAIL PROTECTED]>
Cc: "Heikki Tuuri" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, March 02, 2002 6:19 PM
Subject: Re: InnoDB frightens me...


> On Sat, Mar 02, 2002 at 11:14:42PM +0100, Steve Rapaport wrote:
> >
> > I'm seriously considering switching to mysql-max so I can make my
> > session handling table an Innodb type.  Currently the mysql locking
> > policy allows big traffic jams when several sessions are active
> > simultaneously, and it's the only table that has frequent updates.
> > I need row-locks!
> >
> > BUT, and it's a big but,
> >
> > I just read through the InnoDB manual pages in the mysql site, and
> > it seems I can't have row-locking without a lot of programming and
> > worse, admin overhead.  And scary a-priori decisions.
>
> Hm?
>
> > At first glance (correct me) I need to
> > 1. Check through all my programs handling this table to
> > add AUTOCOMMIT or Commit/Rollback as appropriate.
>
> Only if you want transactions.
>
> > 2. Decide with zero experience on a lot of maximum sizes which will not
be
> > adjustable in future, including dataspace.
>
> You can always add more space later.
>
> > I am sufficiently frightened to just accept table-lock traffic jams
> > instead.  Can anyone tell me how I can use row-locking without
> > getting into this frightening world?
>
> Try out BDB tables, which have page-level locking?
>
> Jeremy
> --
> Jeremy D. Zawodny, <[EMAIL PROTECTED]>
> Technical Yahoo - Yahoo Finance
> Desk: (408) 349-7878   Fax: (408) 349-5454   Cell: (408) 685-5936
>
> MySQL 3.23.47-max: up 23 days, processed 763,640,350 queries (376/sec.
avg)
>
> ---------------------------------------------------------------------
> 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
>


---------------------------------------------------------------------
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

Reply via email to