Professional Documents
Culture Documents
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.
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:
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.
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.
Non-transactional
No data cache
Table-level locking
MyISAM utilities
Three utility programs are designed for working with 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.
$ 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.
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:
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.
myisam_ftdump program provides information about the FULLTEXT indexes in MyISAM tables. You must
specify which index you want the program to analyze.
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
got error 2
The most widely used transactional storage engine is the InnoDB storage engine. InnoDB brought
support for foreign keys to mysqld.
Feature summary:
Row-level locking
It supports a high level of concurrent writes and is heavily used in typical online transactional
environments.
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.
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.
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.
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;