Next Entry  Previous Entry

Nov
5

MySQL Storage Engines

MySQL 2 Comments

Storage engines are responsible for storing and retrieving all the data stored “in” MySQL. Each storage engine has its own strengths and weaknesses that determine its suitability in a particular situation.

MyISAM

MyISAM is the default storage engine in MySQL and provides a good comprimise between performance and features.

Pros:

  • platform independent
  • concurrent inserts
  • full-text indexes
  • compression

Cons:

  • no transations
  • table-level locking
  • potentially long repair times

Good For:

  • applications with many reads and few writes.

InnoDB

InnoDB is a transactional storage engine that uses MVCC and row-level locking, and includes automatic crash recovery.

Pros:

  • ACID transactions
  • row-level locking and MVCC
  • crash recovery
  • clustered indexes
  • foreign key constraints

Cons:

  • alterations to table structure can be slow on large tables

Good For:

  • online ordering and other transaction based applications.

Memory

Memory tables store all their data in memory which means they are very fast because there is no waiting for disk I/O. They also use hash indexes which makes them very fast for lookup queries. The table definition of a Memory table will survive a server restart, but all data will be lost.

Pros:

  • very fast

Cons:

  • uses fixed-length rows which can waste memory
  • table-level locking
  • no support for TEXT or BLOB datatypes
  • no transactions

Used for:

  • lookup or mapping tables
  • caching results of periodically aggregated data
  • intermediate results when analysing data

Archive

The archive engine is optimised for high-speed inserting and data compression. It supports only INSERT and SELECT queries and doesn’t support DELETE, REPLACE, or UPDATE queries, or indexes. Rows are buffered and compressed using zlib as they are inserted which means much less disk I/O than MyISAM tables.

Pros:

  • fast INSERTs
  • compression

Cons:

  • no support for indexes, SELECTs will perform a full table scan.

Uses:

  • storing large amounts of rarely accessed data in a very small footprint, e.g. logs and audit records

CSV

The CSV storage engine stores data in text files using comma-seperated values. Other applications can open the table data file directly and read the contents. Likewise, if an application exports a CSV and saves it in the server’s data directory, the server can read the file straight away. CSV tables do not support indexes.

Uses:

  • data interchange and certain types of logging.

Other Engines

There are several other storage engines available.

  • Blackhole - Essentially a no-op storage engine, all INSERTS are discarded although they are recorded in the binary log and can be replayed on slaves.
  • Federated - Federated tables refer to tables on a remote MySQL server.
  • NDB Cluster - A specialised storage engine designed for high-performance with redundancy and load-balancing capabilities.
  • Falcon - A next-generation storage engine designed for todays hardware (64bit CPUs and plenty of memory).
  • Maria - A replacement for MyISAM that includes transactions, row-level locking, MVCC, and better crash recovery.

Blackhole, Federated and NDB Cluster are suitable only for specific purposes and should only be used after careful consideration. Falcon and Maria are the two modern storage engines although neither are currently considered production-stable.

2 Comments

  1. Mike on 5th November 2008 @ 21:43

    …And coming soon to the storage engine world, ScaleDB for MySQL. It delivers shared-disk clustering and high-performance indexing.

  2. Leyton Jay on 6th November 2008 @ 07:55

    In the past I’ve always found MyISAM to be very good and I’ve always stuck with it.

    But since traffic to my website has increased dramatically this year, I’ve been doing far more writes than reads and at peak times the load on the DBMS has become quite high.

    For these reasons I’ve woken up three times this year to find that my MyISAM tables have locked up during the night as the server has tried to handle multiple, table-locking, I/O requests simultaneously. Being as blogs are database driven, my site effectively goes down until I login and repair the DB.

    So I’m thinking of switching from MyISAM to InnoDB after what you said above about MVCC and row-level locking.

    Cheers!

Leave a comment

required

required (not published)