Quote:
Originally posted by phpslave
row locking instead of table locking could add some benifits, i agree. As long as the overhead of transactions and foreign keys doesn't out weigh those benifits. With InnoDB you do take a preformance hit, but that hit depending on how your tables are done could be well worth it.
As far as INNODB, and 100 million rows plus (sorry 1-2 million) i haven't had any problems with corruption problems in some time. Only when some jackoff has kill -9 my server or when i had hardware failing on the machine. I don't think we have had a table corruption this year at all, however we used to have them all the time about 2 years ago when what we really needed was more servers to help with the load. Simple lookups are usually best handled with INNODB, something with high inserts and lookups InnoDB could be a much better solution.
If nothing else it's something that could be tried and if it didn't work move it back over. It is worth looking into.
Sorry it's late and i'm kinda rambling.
just have a question, have you ever ran into replication problems with InnoDB that you didn't get with INNODB?
|
Not as of yet, however I've had native mysql replication problems in the past using INNODB. I'm waiting to be able to use MySQL's new clustering software, that way I can have asynchronous replication.
In GFY's case, I assume they are doing massive inserts (every post), while tons of selects are being done on the same table, which is why I recommend trying InnoDB out.
Another option might be to run nightly optimizes on their tables if they don't already do so; I know when we had corruption problems, after having it run daily we had no more problems.