Where MySQL wins: nice full text indexing, and, as others have pointed out, it's ubiquitous. It has a few SQL extensions that you'll wish had made it into the standard like "REPLACE INTO." It's nice to use a database that, if you type "show tables" will just show you a list of your tables.

Where it loses: it's unreliable. Not in the sense that it's liable to crash, but in the sense that it provides weak foreign key constraints, has no triggered procedures and transaction-safe tables are an extension.

That means your integrity checking has to be strewn all over your application. Not that redundant integrity checks shouldn't be in your application, but the DBMS should be the failsafe point. You should also be certain that data in the DBMS is correct, even if something goes wrong with the app.

Moreover, the fact is that most MySQL developers don't know how to write integrity checks properly. Let's face facts: these are people who are hacking together a website (that's what I use it for...) and probably wouldn't know of any monitors beyond the one on their desk. Structured exception handling... wow, that's really fun to write, and did you actually do test cases for it?

Proper exception handling requires a degree to understand let alone code, it's incredibly painful to code, and it protects against glitches that rarely happen. Even if you could, why on earth would you ever want to code it when you could let the DBMS take care of all that? You may as well just let the DBMS throw an error and pass it back to the user. Check the error codes for common problems and just tell them it's an unexpected error the rest of the time.

Speed: with MySQL the only way to get proper transaction handling is through InnoDB tables. (And these have all kinds of restrictions on them.) In a real life database, one to which you would actually entrust your valuable data, all those supposed speed benefits go up in smoke.

The only way to be able to do live backups is with InnoDB. Again, if you're doing a business website, live backups is not optional.

MySQL doesn't have stored views or sub-SELECTs. It won't, according to the authors, until someone writes it for them or pays them to do it. What does that mean for you? You get to write lots of iterating loops which will bloat your code making it buggier and harder to update.

Inconsistent table types: There are 6 table types, and the semantics are different for all of them. Example: foreign key constraints only work between InnoDB tables, and full-text indexing only works on MyISAM tables.

Stored procedures: They have to be written in C++. That means that all that iterating you have to do (because there are no sub-SELECTs or stored views) is going to result in repeated round-trips. You can kiss network transparency goodbye.

Anyway, as with any DBMS, there are plenty of minor issues and it carries all the baggage of SQL. These are the problems that prevent the use of MySQL in anything but quick and dirty hacks.