There are several externally-developed storage engines, some of the most popular are:

MySQL has several custom and community storage engines under development:

In some distributions, the default storage engine is MyISAM, which is not transaction safe. Setting the default engine to a transactional engine such as InnoDB is trivial. Beginning with MySQL 5.5.1 InnoDB is the default storage engine.

MySQL has a query cache that does simple string matching before the parser to see whether a query has been processed recently and rapidly returns the result to the client application if it has, without the need to do any of the traditional database work. This is of considerable value to many read-mostly workloads. Cached queries are removed whenever any table involved in the query is changed so its usefulness declines as the rate of data changes increases.

The query cache runs on a single thread and must consider each select, so it may eventually become a performance bottleneck at some point beyond 8 cores, but that's not usually the case. It can be turned off easily to check this and to see whether its small overhead is worthwhile for the particular workload.

MySQL also supports network protocol-level compression which is an option that can be turned on by the client if the server allows it. This compresses everything to and from the server.

MyISAM is the traditional MySQL storage engine and is often better for read-mostly workloads. MySQL's MyISAM engine performs faster than PostgreSQL on simple queries and when concurrency is low or follows certain patterns (e.g. count(*) is very fast). MyISAM's speed comes at the cost of not supporting transactions, table level locking (for writes), foreign keys, and not offering guaranteed data durability.

In old versions, MyISAM required exclusive access for SELECT or data-changing operations. Recent versions default to allowing updates at the end concurrently if there are no deleted records and offer the option to ignore deleted record free space and always operate concurrently, or to disable concurrent inserts.

MyISAM supports leading prefix compression for keys and supports a read only compressed table form that compresses data as well.

System tables always use the MyISAM storage engine. This has been used to criticise it for the potential of losing system table information, but some claim that this doesn't happen "in practice" as it is unlikely that such generally infrequently updated tables will be in the process of being written to at the time of a crash.

InnoDB is an ACID compliant, transactional storage engine using MVCC technology. It's the normal choice for most modern applications using MySQL.

The InnoDB storage engine stores the data with the primary key, so primary key lookups are fast. Good choice of primary key for physical optimisation can be very useful; in cases where it's undesirable or where the desired primary key produces poor physical performance a simple integer can be used. An internal integer primary key is the default if no primary key or unique column is present.

The InnoDB engine automatically generates hash index entries when processing SELECTs. This feature can be turned off if necessary; some workloads perform better without it.

The InnoDB engine has an insert buffer that caches updates to secondary index entries and applies them in the background. This can significantly speed up inserts, reducing the number of physical writes required by combining many updates. If a secondary index page has outstanding updates when it is needed for a query the updates will be merged first. As of version 5.5 the insert buffer is also used as a buffer for other types of writes, improving the performance of UPDATE queries as well.

With the InnoDB installed via Plugin MySQL 5.1 supports on-the-fly compression of InnoDB tables.

Beginning with this release of the InnoDB Plugin, you can use the attributes ROW_FORMAT=COMPRESSED or KEY_BLOCK_SIZE in the CREATE TABLE and ALTER TABLE commands to request InnoDB to compress each page to 1K, 2K, 4K, 8K, or 16K bytes.

— InnoBASE OY , 

Despite major changes in ownership in recent years, InnoDB performance has received continuing development attention.

With InnoDB, the secondary key lookup is slow, because the leaves of its secondary indices are the primary keys. So it has to do 2 lookups when using a secondary index: one for the secondary index itself, and one for the primary key.