A very interesting and informative article that talks about the different storage engines available the MySQL may be read here.
You can use the show engines; command to see what storage engines your installation of MySQL knows about and which ones are available. For instance, here on my laptop, the following list is revealed:
mysql> show engines;
+------------+---------+------------------------------------------------------------+
| Engine | Support | Comment |
+------------+---------+------------------------------------------------------------+
| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance |
| HEAP | YES | Alias for MEMORY |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables |
| MERGE | YES | Collection of identical MyISAM tables |
| MRG_MYISAM | YES | Alias for MERGE |
| ISAM | NO | Obsolete storage engine, now replaced by MyISAM |
| MRG_ISAM | NO | Obsolete storage engine, now replaced by MERGE |
| InnoDB | YES | Supports transactions, row-level locking, and foreign keys |
| INNOBASE | YES | Alias for INNODB |
| BDB | NO | Supports transactions and page-level locking |
| BERKELEYDB | NO | Alias for BDB |
| NDBCLUSTER | NO | Clustered, fault-tolerant, memory-based tables |
| NDB | NO | Alias for NDBCLUSTER |
| EXAMPLE | NO | Example storage engine |
| ARCHIVE | YES | Archive storage engine |
| CSV | NO | CSV storage engine |
| BLACKHOLE | NO | Storage engine designed to act as null storage |
+------------+---------+------------------------------------------------------------+
Older versions of MySQL may require you to use the command show variables like 'have_%';.
Decisions about which engine type to use for a given table should be made based upon the following criteria:
- supported field and data types
- locking types (Note: Only the InnoDB supports row-level locking)
- indexing
- transactions
Here are excepts from this article, which I encourage you to read in its entirety.
MyISAM
This is the default engine type. Offers the best combination of performance and functionality, but lacks transaction capabilities and uses table-level locking.
MERGE
The MERGE engine type allows you to combine a number of identical tables into a single table. You can then execute queries that return the results from multiple tables as if they were just one table. Each table merged must have the same table definition.
MEMORY
The MEMORY storage engine (previously known as the HEAP storage engine) stores all data in memory; once the MySQL server has been shut down any information stored in a MEMORY database will have been lost. However, the format of the individual tables is kept and this enables you to create temporary tables that can be used to store information for quick access without having to recreate the tables each time the database server is started.
EXAMPLE
The EXAMPLE engine is actually a programming example of a storage engine that can be used as the basis for other engines within the MySQL system. It does not support data inserts and isn’t a practical engine for any form of database access. It is, however, a good guide to how to develop your own storage engine, and is therefore an effective guide for programmers.
FEDERATED
The FEDERATED storage engine (added in MySQL 5.03) enables you to access data from remote MySQL database (other databases may be supported in the future) as if it were a local database. In effect, the MySQL server acts as a proxy to the remote server, using the MySQL client access library to connect to the remote host, execute queries and then reformat the data into the localized format.
ARCHIVE
The ARCHIVE storage engine supports only the INSERT and SELECT statements, but does support most of the MySQL field types. Information stored in an ARCHIVE storage engine table is compressed and cannot be modified and so ARCHIVE tables are perfect for storing log data (which you don’t want to be able to change) or information that is no longer in active use (for example, old invoicing or sales data).
CSV
The CSV storage engine stores data not in a binary format, but in the form a CSV (Command Separated Values) file. Because of this, there are limitations to the data stored. It is not an efficient method for storing large volumes of data, or larger data types like BLOB, although such types are supported. There is also no indexing. However, because the data is stored in the CSV format it is exceedingly portable; these CSV files generated can easily be imported into many different software packages, including Excel, OpenOffice and database systems like Access or FileMaker.
In general, the CSV engine is impractical as a general database engine. It is, however, probably the most effective and easiest method for data exchange. What makes it so convenient is that we can use SELECT and INSERT statements to create the database, which in turn means that we can easily produce CSV files based on queries of other data.
With some careful work, the CSV storage engine can also be used as an effective way of getting information into MySQL. Here, you can create the tables first, shutdown the MySQL server, copy over CSV files that you have exported from Excel, Access or another database, and you can then import the data and copy it over to MyISAM or InnoDB tables.
BLACKHOLE
Strange though it may seem, the BLACKHOLE engine does not actually store any data. Although you can create tables and indexes, all SQL statements that would add or update information to the database are executed without actually writing any data. The database structure is retained, however, and you can create any indexes on the (non-existent) information that you want.
Although this seems like a futile exercise, it does allow you to test out database structures and play with table definitions without actually creating any data. Even more useful, however, is that SQL statements on BLACKHOLE databases are written to the binary log, and therefore are replicated to slave databases.
ISAM
The ISAM storage engine was the original engine type available with versions of MySQL up until MySQL 3.23, when the MyISAM storage engine was introduced. ISAM has a number of different limitations that make it impractical as a database engine.
ISAM is included for backwards compatibility, you certainly shouldn’t use ISAM for new databases, use MyISAM instead.
Berkeley DB (BDB)
The Berkeley DB (or BDB) engine is based on the technology provided by the Berkeley DB storage system developed by SleepyCat software. BDB is a hash based storage mechanism, and the keys to the hash values are stored very efficiently. This makes the recovery of information–especially when accessed directly using a unique key incredibly quick, and by far the quickest of the available database types. Recovering full records is even quicker if you the data is short enough to be stored with the unique key (i.e., under 1024 bytes long). BDB is also one of only two types of storage engine that support transactions.
InnoDB
The InnoDB Engine is provided by Innobase Oy and supports all of the database functionality (and more) of MyISAM engine and also adds full transaction capabilities (with full ACID (Atomicity, Consistency, Isolation, and Durability) compliance) and row level locking of data.
| Engine |
Introduced |
Default Install |
Data Limitations |
Index Limitations |
Transaction Support |
Locking Level |
| MyISAM |
v3.23 |
Yes |
None |
64 indexes per table (32 pre 4.1.2) |
No |
Table |
| MERGE |
v3.23.25 |
Yes |
Underlying tables must be MyISAM |
N/A |
No |
Table |
| MEMORY |
1.0 (only known as MEMORY since 4.1) |
Yes |
BLOB and TEXT types not supported |
None |
No |
Table |
| EXAMPLE |
v4.1.3 |
No |
N/A |
N/A |
N/A |
N/A |
| FEDERATED |
v5.0 |
No |
Limited by remote database |
N/A |
No |
N/A |
| ARCHIVE |
v4.1.3 |
No |
Data can only be inserted (no updates) |
N/A |
No |
N/A |
| CSV |
v4.1.4 |
No |
None |
Indexing not supported |
No |
Table |
| BLACKHOLE |
v4.1.11 |
No |
No data is stored, but statements are written to the binary log (and therefore distributed to slave databases) |
N/A |
No |
N/A |
| ISAM |
v1.0 |
Yes |
Limited maximum database size (4GB) |
Maximum 16 indexes per table, 16 parts per key |
No |
Table |
| BDB |
v3.23.34a |
No |
None |
Max 31 indexes per table, 16 columns per index;max key size 1024 bytes |
Yes |
Page (8192 bytes) |
| InnoDB |
v3.23 (source only), v4.0 (source and binary) |
No |
None |
None |
Yes (ACID compliant) |
Row |