Making something reliant on InnoDB is a big mistake. Though they are better in many aspects, they are not available everywhere. The caveat here is that MySQL will let you say "CREATE TABLE ... Type=InnoDB" even if you DO NOT have InnoDB functionality in the back end. I tested this myself on a server running Mandrake Linux, and the behavior is what I outlined above: no error given, nothing. The user could be fooled into thinking they are running InnoDB while they are not. I would imagine that MySQL will allow you to have FOR UPDATE on MyISAM tables, and will simply ignore it, like it does in many other statements it does not support. On servers that you have control of, you must load a package called MySQL-MaxDB to get Inno support. Since most people are on shared hosting, this would be a source of great confusion, and perhaps serious problems (assume that locking is happening while it is not, ...etc.) So, we have to be careful with mandating InnoDB. If we do, it has to be an option, not mandatory. --- Gerhard says: On Mon, 2 May 2005, Karoly Negyesi wrote:
Do you have experience with using InnoDB? Does it have other (dis)advantages? Should we consider to use InnoDB for some tables?
No. Slow.
I think this is too narrow minded. If InnoDB would give us some usefull features, we should consider to try using them and do benchmarks. I can imagine that for some tables being a bit slow isn't a real problem, but row based locking might be a significant improvement. For example we could have a "locks" table that looks similar to this: