Set up a load test system which is as near a replica of your
production environment as possible. Capture an hour's worth of
transactions. Load an copy of your database. Play the queries in and
see how long it takes.
Any advice without taking something like the above steps is pure
speculation, and any change a gamble. It depends on so many factors
(locking contention, where the bottlenecks are, what the access
pattern is, configuration of disks, etc) that there is no clear-cut
answer to your question.
Other than, "it might" :). Set up a micro-version of your
application, see if you can convince yourself that there might be
On Mon, 05 Jan 2004 21:02, Travis Reeder wrote;
> I'm sure this has been asked before, but I cannot find solid evidence
> to whether switching would provide us with any benefits.
> We currently run MyIsam tables on 4.1.x and we are continuously
> processing 24 hours/day and using about 20 tables heavily. The process
> is generally doing Updates or Inserts depending on whether the row is
> available for updates, otherwise new rose is inserted and then updates
> until the next time bucket. It's always a different time bucket
> not always the same row being used. We found that running 3 processing
> threads seems to be around optimal (10 was too many, 1 was too little)
> for being able to process the maximum amount. Mysql runs at 100%
> much constantly.
> Now would InnoDB help in this situation? Would it allow us to increase
> the thread count to push more through in a shorter amount of time
> (because the tables wouldn't be locking)?
> And if so, would it be enough to justify the extra space required for
Sam Vilain, sam@stripped
Please dont lie to me, unless youre absolutely sure Ill never find
out the truth.