My experience and training have hammered home the point that Decision Support (DSS) and On Line Transaction Processing (OLTP) present different challenges and loads on database servers.

All DSS, which is read-only, really needs is good indices, logical, and physical design. A lot of RAM allocated to the data cache helps, since reading from cache is a whole lot faster than reading from disk.

OLTP, on the other hand, needs to assure data integrity while rows are inserted, deleted, and modified. Triggers, declarative constraints, procedures, rules, defaults, and transaction processing with commits and rollbacks all come into play here, and this takes cpu cycles and well as physical reads and writes to the database.

Concurrency and data integrity, thus, are often at loggerheads when it comes to database design. We have here the "2 out of 3" principle in operation:

You can have it quickly;
You can have it cheaply;
or you can have it right --

But you can only have two of the three.

MySQL excels at DSS applications, but a production database where data integrity is crucial needs more than MySQL is able to offer. We use a full-featured RDBMS for our production databases, but several smaller applications are using MySQL. It's a question of using the appropriate tool for the job.

-----
"Computeri non cogitant, ergo non sunt"