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 benefits. On Mon, 05 Jan 2004 21:02, Travis Reeder wrote; > Hi, > > I'm sure this has been asked before, but I cannot find solid evidence as > 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 though, > 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% pretty > 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 > innodb? -- Sam Vilain, [EMAIL PROTECTED] Please dont lie to me, unless youre absolutely sure Ill never find out the truth. ASHLEIGH BRILLIANT -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
