You are on page 1of 12

Mafisco Book Summary on MySQL Storage Engines

Table of Contents
Over view ...................................................................................................................................................... 2
Storage engine comparison .......................................................................................................................... 2
Storage Engine Overview Summary Table .................................................................................................... 3
MyISAM storage engine ................................................................................................................................ 4
MyISAM Feature summary ....................................................................................................................... 5
Some MyISAM Configuration Options ...................................................................................................... 6
MyISAM utilities ........................................................................................................................................ 6
myisamchk ............................................................................................................................................ 6
myisampack .............................................................................................................................................. 7
InnoDB storage engine.................................................................................................................................. 9
Tablespace configuration variables .......................................................................................................... 9
Performance configuration variables ......................................................................................................... 10
Over view

Most database administrators regularly work with two storage engines, MyISAM and InnoDB. A storage
engine is a subsystem that manages tables. Most database management systems have one subsystem to
manage tables but MySQL Server can use different subsystems. A storage engine is applied or
implemented at the table level and is sometimes called table type. CREATE TABLE and ALTER TABLE
statements can use the ENGINE option to set (or change) the storage engine that is associated with the
table.
MySQL has a pluggable storage engine architectural design. The code that manages the tables (the
storage engine) is different from the database server core code. The core code manages the
components such as the query cache, the optimizer, and the connection handler. The storage engine
code handles the actual I/O of the table.

This separation of code allows for multiple storage engines to be used by the same core server. This
capability allows DBA or developers to choose a storage engine based on its ability to meet the
requirements of an application.

InnoDB is the most frequently used transactional storage engine. Storage engines were implemented as
plugins in MySQL Server version 5.1. The pluggable part of pluggable storage engines reflects the
separation of code, not the nature of how to add a storage engine (compiled-in vs. plugin).

Previously the release cycle of the storage engine plugin was independent from the server as InnoDB
was owned by Innobase Oy. This meant that a new version of the storage engine plugin could be
released at any time and an administrator can upgrade just that one component.

Using the plugin, a database administrator can upgrade the plugin instead of the entire MySQL Server,
and have added functionality.

Storage engine comparison

You can easily use multiple storage engines in a single application leading to optimal results your
application because different parts of the application will have different requirements that one storage
engine cannot be a perfect fit for.

Some features and abilities that make one storage engine different from another include:

Transaction supportSupport of transactions requires more overhead in terms of memory,


storage space, and CPU usage. Every application does not require transactions and using a non-
transactional storage engine can be faster in some cases.
Table-level features MySQL provides a handler for tables to have a CHECKSUM attribute,
which can be seen in the TABLES system view in the INFORMATION_SCHEMA database.
Whether or not the table has a value for CHECKSUM depends on the storage engineonly
MyISAM currently handles the CHECKSUM attribute.
Locking MySQL Server supports the ability to lock an entire table. However, storage engines
can implement their own locking methods, to be able to lock at more granular levels, such as
locking a set of rows.
Index implementationDifferent applications can benefit from different index implementation
strategies. Several common methods of implementing indexing exist and the designers of each
storage engine choose the one they think will perform best in their targeted situation.
Foreign keysusing foreign keys to enforce relational integrity among tables is quite common.
Not every application needs foreign keys and many storage engines do not support them.
Buffering Data, index, and log buffers are handled by storage engines. Some choose not to
implement buffering in some areas at all, and others can allow multiple buffers. For example,
MyISAM does not have a buffer for data, but supports multiple buffers for indexes.
File storage some storage engines store their data and indexes in self-contained files,
meaning that a table can be copied by copying the files. Other storage engines use centralized
metadata, and thus a table cannot be copied simply by copying the data and index files.
Backupsome storage engines have tools to allow consistent, non-blocking backups to be
taken, whereas others will cause application disruption if a backup is run while the table is in use
by the application.

Carefully weigh your applications requirements before selecting a particular storage engine for use. Be
careful when changing the storage engine that handles a table because the entire table must be rebuilt,
which can take a long time for large tables.

Storage Engine Overview Summary Table


MyISAM storage engine

It is non-transactional and does not implement additional locking mechanisms. MyISAM depends on the
global table-level locking in MySQL, but because it has very little overhead can be quite fast for reads. A
large number of concurrent writes to a MyISAM table can be problematic. If your application has a lot of
write activity, the writes will end up blocking the reads and your database server might exhibit a high
number of connections to the server as SELECT statements are blocked waiting for any write threads to
complete. If your application has this problem you should consider using a storage engine such as
InnoDB or Falcon that locks at the row level instead of the table level.

One method of reducing the contention between reads and writes to a MyISAM table is allowing what
are called concurrent inserts. Concurrent inserts allow more than one insert at a time to be added at
the end of a table. The concurrent_insert option to mysqld defaults to 1, meaning that inserts are
allowed at the same time as reads if there are no data gaps caused by UPDATE or DELETE statements. A
value of 2 indicates that inserts are allowed regardless of data gaps and a value of 0 means concurrent
inserts are not allowed.

There are three files on disk that represent a MyISAM table. Those three files have the table name and
an extension, where the extension is either:
frm for the table format file,
MYD for the data file, or
MYI for the index file.

The three files compromising a table are the entire table, meaning they can be copied without any
problem from the server to a backup location for a raw backup or even directly to another server for use
on a new server.

The tables should not be written to when the files are being copied off or there will be a possibility of
corruption.

Note: Place a read lock or shutting down mysqld before copying table files.

Also, the target server must be of the same endian format as the source server, means that the servers
use the same byte order. E.g you cannot copy MyISAM tables from an x86 or x86_64 server to a SPARC
server, because they do not have the same endian format but you could copy from an x86-based Linux
server to a Windows-based server, because they use the same endian format.

MyISAM Feature summary

Non-transactional

No foreign key support

FULLTEXT indexes for text matching

No data cache

Index caches can be specified by name

Implements both HASH and BTREE indexes (BTREE by default)

Table-level locking

Very fast read activity, suitable for data warehouses

Compressed data (with myisampack)

Online backup with mysqlhotcopy

Maximum of 64 indexes per table


Some MyISAM Configuration Options

MyISAM utilities
Three utility programs are designed for working with MyISAM tables:

myisamchkused to analyze, optimize, and repair MyISAM tables.


myisampackused to create compressed, read-only MyISAM tables.
myisam_ftdumpused to display information about fulltext fields in MyISAM tables

Each program must be run locally on the server where the MyISAM tables are located.

myisamchk

The myisamchk program has four different modes of operation: It can be used to analyze, optimize,
check, and repair MyISAM tables. The default mode of operation is the check mode where it checks for
possible corruption. You can specify a specify table to check or you can also use with wildcard
conditions. Wildcard conditions make it easy to have it check all tables in a database.
When running myisamchk you must manually block all access to the tables being checked. Otherwise,
corruption could occur. The easiest and best way to accomplish this is simply to shut down mysqld. If
you need to check tables while mysqld is running, consider using the CHECK TABLE command.

Check all the MyISAM tables in the MySQL database:

Check all the MyISAM tables in the mysql database:

$ myisamchk /var/lib/mysql/mysql*.MYI

The utility actually checks the index files of the MyISAM tables. If any of the tables needed repair you
could just run:

$ myisamchk r /var/lib/mysql/mysql/table_name.MYI

myisampack

It's used to create compressed read-only versions of tables can provide for a good performance increase
for data that is no longer being updated but still needs to be accessed. Stop the database server before
running myisampack to ensure the tables are not written to in order to avoid corruption. so run FLUSH
TABLES WITH READ LOCK or stop the server.

The Archive storage engine has better compression than read-only MyISAM tables and can support only
one index while a compressed MyISAM table is read-only, and cannot have new rows inserted like an
Archive table can.

Running myisampack: Do it in the data directory of the database the table is in

Specify the MyISAM index file (.MYI) of the table you are compressing.
shell> myisampack table_name.MYI

Once the compression is done you have to run the myisamchk program to rebuild indexes. For optimal
performance you can also sort the index block and analyze the table to help the optimizer work better:

shell> myisamchk --rq --sort-index analyze table_name_MYI

If the compression process was done while the server is online with FLUSH TABLES WITH READ LOCK
release any read locks on the table using UNLOCK TABLES and issue a FLUSH TABLES command to force
mysqld to recognize and begin using the new table.

If mysqld was shut down, restart it.

myisam_ftdump program provides information about the FULLTEXT indexes in MyISAM tables. You must
specify which index you want the program to analyze.

Use SHOW CREATE TABLE command to get index information

mysql> SHOW CREATE TABLE film_text\G

Notice that FULLTEXT KEY is listed second, after the PRIMARY KEY. To specify the appropriate index
you provide a number. The numbering begins at 0 so this text index is number 1.

To run myisam_ftdump, change to the directory where the table files are:

cd /var/lib/mysql/sakila

shell> myisam_ftdump film_text 1


If you do not run myisam_ftdump in the directory where the table files are you will get an error:

got error 2

InnoDB storage engine

The most widely used transactional storage engine is the InnoDB storage engine. InnoDB brought
support for foreign keys to mysqld.

Feature summary:

Transactional support provided by MVCC (Multi Version Concurrency Control)

Row-level locking

Foreign key support

Indexing using clustered B-tree indexes

Configurable buffer caching of both indexes and data

Online non-blocking backup through separate commercial backup program

It supports a high level of concurrent writes and is heavily used in typical online transactional
environments.

Tablespace configuration variables

A tablespace is a logical group of one or more data files in a database. The InnoDB storage engine allows
you to have control over the format and the location of the tablespace.
Some variables used to configure the tablespace:

You cannot move InnoDB table files around as you can MyISAM tables. When the
innodb_file_per_table option is set, the .ibd file contains the data and indexes for an InnoDB
table; however, the shared tablespace still contains metadata. Copying the .ibd file to another
server will not result in actually copying the table.

Performance configuration variables

Some variables directly affect the performance of your InnoDB tables include:
A larger buffer configured by innodb_buffer_pool_size means there is less I/O needed to access data in
tables. This is because the InnoDB storage engine stores your frequently used data in memory. This
should be a significant percentage of the total memory available to mysqld but be very careful with this
setting because if it is configured to use too much memory it will cause swapping by the operating
system, which is very bad for mysqld performance. Using too much memory will cause mysqld to crash.

SHOW ENGINE InnoDB STATUS

This command is used to provide detailed information about the workings of the InnoDB storage engine.
It breaks down into nine sections. Its useful when debugging problems relating to the InnoDB engine.
All statistics are calculated using data from either the time of the last run of SHOW ENGINE INNODB
STATUS or the last system reset. The length of time used for calculations is displayed in the header
information.

It is possible to have InnoDB configured to write the same information shown by SHOW ENGINE InnoDB
STATUS to the standard output of mysqld. Standard output would typically be your error log.

This done by creating a table called innodb_monitor:

mysql> CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB;

mysql> SHOW ENGINE INNODB STATUS\G

Its used for debugging problems relating to the InnoDB engine.

Now until you drop the table it will log similar information as was shown previously to your standard
output every fifteen seconds. When you are done troubleshooting the issue, just drop the table:
mysql> DROP TABLE innodb_monitor;

InnoDB Status Sections Include:

You might also like