MySQL supports several storage engines that act as handlers for different
table types. MySQL storage engines include both those that handle
transaction-safe tables and those that handle non-transaction-safe tables:
The original storage engine was ISAM, which
managed non-transactional tables. This engine has been replaced by
MyISAM and should no longer be used. It is deprecated in MySQL
4.1, and is removed in subsequent MySQL release series.
In MySQL 3.23.0, the MyISAM and
HEAP storage engines were introduced.
MyISAM is an improved replacement for
ISAM. The HEAP
storage engine provides in-memory tables. The
MERGE
storage engine was added in MySQL 3.23.25. It allows a collection of
identical MyISAM tables to be handled as a
single table. All three of these storage engines handle
non-transactional tables, and all are included in MySQL by default. Note
that the HEAP storage engine has been
renamed the MEMORY engine.
The InnoDB and BDB
storage engines that handle transaction-safe tables were introduced in
later versions of MySQL 3.23. Both are available in source distributions
as of MySQL 3.23.34a. BDB is included in
MySQL-Max binary distributions on those operating systems that support
it. InnoDB also is included in MySQL-Max
binary distributions for MySQL 3.23. Beginning with MySQL 4.0,
InnoDB is included by default in all MySQL binary distributions.
In source distributions, you can enable or disable either engine by
configuring MySQL as you like.
The EXAMPLE storage engine was added in
MySQL 4.1.3. It is a “stub” engine that does
nothing. You can create tables with this engine, but no data can be
stored in them or retrieved from them. The purpose of this engine is to
serve as an example in the MySQL source code that illustrates how to
begin writing new storage engines. As such, it is primarily of interest
to developers.
NDB Cluster is the storage engine used by
MySQL Cluster to implement tables that are partitioned over many
computers. It is available in source code distributions as of MySQL
4.1.2 and binary distributions as of MySQL-Max 4.1.3.
The ARCHIVE storage engine was added in
MySQL 4.1.3. It is used for storing large amounts of data without
indexes in a very small footprint.
The CSV storage engine was added in MySQL
4.1.4. This engine stores data in text files using comma-separated
values format.
The BLACKHOLE storage engine was added in
MySQL 4.1.11. This engine accepts but does not store data and retrievals
always return an empty set.
This chapter describes each of the MySQL storage engines except for
NDB Cluster, which is covered in
Chapter 15,
MySQL Cluster.
When you create a new table, you can specify which storage engine to use by
adding an ENGINE or
TYPE table option to the
CREATE TABLE statement:
CREATE TABLE t (i INT) ENGINE = INNODB;
CREATE TABLE t (i INT) TYPE = MEMORY;
ENGINE is the preferred term, but cannot be
used before MySQL 4.0.18. TYPE is available
beginning with MySQL 3.23.0, the first version of MySQL for which multiple
storage engines were available. TYPE is
supported for backward compatibility but is deprecated.
If you omit the ENGINE or
TYPE
option, the default storage engine is used. Normally, this is
MyISAM, but you can change it by using the
--default-storage-engine or
--default-table-type server startup option, or
by setting the default-storage-engine or
default-table-type option in the
my.cnf configuration file.
You can set the default storage engine to be used during the current session
by setting the storage_engine or
table_type variable:
SET storage_engine=MYISAM;
SET table_type=BDB;
When MySQL is installed on Windows using the MySQL Configuration Wizard, the
InnoDB storage engine can be selected as the default instead of
MyISAM. See
Section 2.3.4.6, “The Database Usage Dialog”.
To convert a table from one storage engine to another, use an
ALTER TABLE statement that indicates the new
engine:
ALTER TABLE t ENGINE = MYISAM;
ALTER TABLE t TYPE = BDB;
If you try to use a storage engine that is not compiled in or that is
compiled in but deactivated, MySQL instead creates a table using the default
storage engine, usually MyISAM). (Before MySQL,
MyISAM is always used for unavailable storage engines.) type
MyISAM. This behavior is convenient when you want to copy tables
between MySQL servers that support different storage engines. (For example,
in a replication setup, perhaps your master server supports transactional
storage engines for increased safety, but the slave servers use only
non-transactional storage engines for greater speed.)
This automatic substitution of the default storage engine for unavailable
engines can be confusing for new MySQL users. In MySQL 4.1, a warning is
generated when a storage engine is automatically changed.
For new tables, MySQL always creates an .frm
file to hold the table and column definitions. The table's index and data
may be stored in one or more other files, depending on the storage engine.
The server creates the .frm
file above the storage engine level. Individual storage engines create any
additional files required for the tables that they manage.
A database may contain tables of different types. That is, tables need not
all be created with the same storage engine.
Transaction-safe tables (TSTs) have several advantages over
non-transaction-safe tables (NTSTs):
They are safer. Even if MySQL crashes or you get hardware problems, you
can get your data back, either by automatic recovery or from a backup
plus the transaction log.
You can combine many statements and accept them all at the same time
with the COMMIT statement (if autocommit is
disabled).
You can execute ROLLBACK to ignore your
changes (if autocommit is disabled).
If an update fails, all of your changes are reverted. (With
non-transaction-safe tables, all changes that have taken place are
permanent.)
Transaction-safe storage engines can provide better concurrency for
tables that get many updates concurrently with reads.
You can combine transaction-safe and non-transaction-safe tables in the same
statements to get the best of both worlds. However, although MySQL supports
several transaction-safe storage engines, for best results, you should not
mix different storage engines within a transaction with autocommit disabled.
For example, if you do this, changes to non-transaction-safe tables still
are committed immediately and cannot be rolled back. For information about
this and other problems that can occur in transactions that use mixed
storage engines, see
Section 13.4.1, “START TRANSACTION,
COMMIT, and ROLLBACK Syntax”.
Note that to use the InnoDB storage engine in
MySQL 3.23, you must configure at least the
innodb_data_file_path startup option. In 4.0
and up, InnoDB uses default configuration
values if you specify none. See
Section 14.2.4, “InnoDB Configuration”.
Non-transaction-safe tables have several advantages of their own, all of
which occur because there is no transaction overhead:
MyISAM is the default storage engine as of
MySQL 3.23. It is based on the ISAM code
but has many useful extensions.
Each MyISAM table is stored on disk in three
files. The files have names that begin with the table name and have an
extension to indicate the file type. An
.frm file stores the table format. The data
file has an .MYD (MYData)
extension. The index file has an .MYI
(MYIndex) extension.
To specify explicitly that you want a MyISAM
table, indicate that with an ENGINE table
option:
CREATE TABLE t (i INT) ENGINE = MYISAM;
The older term TYPE is supported as a synonym
for ENGINE for backward compatibility, but
ENGINE is the preferred term from MySQL
4.0.18 on and TYPE is deprecated.
Normally, the ENGINE or
TYPE
option is unnecessary; MyISAM is the default
storage engine unless the default has been changed. To ensure that
MyISAM is used in situations where the
default might have been changed, specify the storage engine explicitly.
The following characteristics of the MyISAM
storage engine are improvements over the older
ISAM engine:
All data values are stored with the low byte first. This makes the
data machine and operating system independent. The only requirements
for binary portability are that the machine uses two's-complement
signed integers and IEEE floating-point format. These requirements
are widely used among mainstream machines. Binary compatibility
might not be applicable to embedded systems, which sometimes have
peculiar processors.
There is no significant speed penalty for storing data low byte first;
the bytes in a table row normally are unaligned and it takes little
more processing to read an unaligned byte in order than in reverse
order. Also, the code in the server that fetches column values is
not time critical compared to other code.
All numeric key values are stored with the high byte first to allow
better index compression.
Large files (up to 63-bit file length) are supported on filesystems
and operating systems that support large files.
Dynamic-sized rows are much less fragmented when mixing deletes with
updates and inserts. This is done by automatically combining
adjacent deleted blocks and by extending blocks if the next block is
deleted.
The maximum number of indexes per table is 64 (32 before MySQL 4.1.2).
This can be changed by changing the source and recompiling. The
maximum number of columns per index is 16.
The maximum key length is 1000 bytes (500 before MySQL 4.1.2). This
can be changed by changing the source and recompiling. For the case
of a key longer than 250 bytes, a larger key block size than the
default of 1024 bytes is used.
Index files are usually much smaller with
MyISAM than with
ISAM. This means that MyISAM
normally uses less system resources than ISAM,
but needs more CPU time when inserting data into a compressed index.
When rows are inserted in sorted order (as when you are using an
AUTO_INCREMENT column), the index tree is split so that the
high node only contains one key. This improves space utilization in
the index tree.
Internal handling of one AUTO_INCREMENT
column per table is supported. MyISAM
automatically updates this column for
INSERT/UPDATE. This makes
AUTO_INCREMENT columns faster (at least
10%). Values at the top of the sequence are not reused after being
deleted as they are with ISAM. (When an
AUTO_INCREMENT column is defined as the last column of a
multiple-column index, reuse of values deleted from the top of a
sequence does occur.) The
AUTO_INCREMENT value can be reset with
ALTER TABLE or
myisamchk.
Dynamic-sized rows are much less fragmented when mixing deletes with
updates and inserts. This is done by automatically combining
adjacent deleted blocks and by extending blocks if the next block is
deleted.
If a table has no free blocks in the middle of the data file, you can
INSERT new rows into it at the same time that other threads
are reading from the table. (These are known as concurrent inserts.)
A free block can occur as a result of deleting rows or an update of
a dynamic length row with more data than its current contents. When
all free blocks are used up (filled in), future inserts become
concurrent again. See
Section 7.3.3, “Concurrent Inserts”.
You can put the data file and index file on different directories to
get more speed with the DATA DIRECTORY
and INDEX DIRECTORY
table options to CREATE TABLE. See
Section 13.1.5, “CREATE TABLE Syntax”.
BLOB and TEXT
columns can be indexed.
NULL values are allowed in indexed
columns. This takes 0-1 bytes per key.
As of MySQL 4.1, each character column can have a different character
set.
There is a flag in the MyISAM index file
that indicates whether the table was closed correctly. If
mysqld is started with
the
--myisam-recover option,
MyISAM tables are automatically checked
when opened, and are repaired if the table wasn't closed properly.
myisamchk marks tables
as checked if you run it with the
--update-state option.
myisamchk --fast checks
only those tables that don't have this mark.
myisamchk --analyze
stores statistics for portions of keys, not only for whole keys as
in
ISAM.
myisampack can pack
BLOB
and VARCHAR columns;
pack_isam cannot.
MyISAM also supports the following features,
which MySQL will be able to use in the near future:
Support for a true VARCHAR type; a
VARCHAR column starts with a length
stored in one or two bytes.
Tables with VARCHAR columns may have
fixed or dynamic row length.
The sum of the lengths of the VARCHAR and
CHAR columns in a table may be up to
64KB.
A hashed computed index can be used for
UNIQUE. This allows you to have
UNIQUE on any combination of columns in a
table. (However, you cannot search on a
UNIQUE computed index.)
Set the mode for automatic recovery of crashed
MyISAM tables.
--delay-key-write=ALL
Don't flush key buffers between writes for any
MyISAM table.
Note: If you do this, you
should not access MyISAM tables from
another program (such as from another MySQL server or with
myisamchk) when the
tables are in use. Doing so risks index corruption. Using
--external-locking does not eliminate
this risk.
The size of the tree cache used in bulk insert optimization.
Note: This is a limit
per thread!
myisam_max_extra_sort_file_size
Used to help MySQL to decide when to use the slow but safe key cache
index creation method.
Note: This parameter is
given in megabytes before MySQL 4.0.3, and in bytes as of 4.0.3.
myisam_max_sort_file_size
The maximum size of the temporary file that MySQL is allowed to use
while re-creating a MyISAM index
(during REPAIR TABLE,
ALTER TABLE, or LOAD DATA INFILE).
If the file size would be larger than this value, the index is
created using the key cache instead, which is slower. This variable
was added in MySQL 3.23.37.
Note: The value is given
in megabytes before 4.0.3 and in bytes thereafter.
myisam_sort_buffer_size
Set the size of the buffer used when recovering tables.
Automatic recovery is activated if you start
mysqld with the
--myisam-recover option. In this case, when
the server opens a MyISAM table, it checks
whether the table is marked as crashed or whether the open count
variable for the table is not 0 and you are running the server with
external locking disabled. If either of these conditions is true, the
following happens:
The server checks the table for errors.
If the server finds an error, it tries to do a fast table repair
(with sorting and without re-creating the data file).
If the repair fails because of an error in the data file (for
example, a duplicate-key error), the server tries again, this time
re-creating the data file.
If the repair still fails, the server tries once more with the old
repair option method (write row by row without sorting). This method
should be able to repair any type of error and has low disk space
requirements.
If the recovery wouldn't be able to recover all rows from previously
completed statementas and you didn't specify
FORCE in the value of the
--myisam-recover option, automatic repair
aborts with an error message in the error log:
Error: Couldn't repair table: test.g00pages
If you specify FORCE, a warning like this
is written instead:
Warning: Found 344 of 354 rows when repairing ./test/g00pages
Note that if the automatic recovery value includes
BACKUP, the recovery process creates files
with names of the form
tbl_name-datetime.BAK.
You should have a cron
script that automatically moves these files from the database
directories to backup media.
14.1.2. Space Needed for Keys
MyISAM tables use B-tree indexes. You can
roughly calculate the size for the index file as
(key_length+4)/0.67, summed over all keys.
This is for the worst case when all keys are inserted in sorted order
and the table doesn't have any compressed keys.
String indexes are space compressed. If the first index part is a
string, it is also prefix compressed. Space compression makes the index
file smaller than the worst-case figure if a string column has a lot of
trailing space or is a
VARCHAR column that is not always used to
the full length. Prefix compression is used on keys that start with a
string. Prefix compression helps if there are many strings with an
identical prefix.
In MyISAM tables, you can also prefix
compress numbers by specifying the
PACK_KEYS=1 table option when you create
the table. Numbers are stored with the high byte first, so this helps
when you have many integer keys that have an identical prefix.
MyISAM supports three different storage
formats. Two of them, fixed and dynamic format, are chosen automatically
depending on the type of columns you are using. The third, compressed
format, can be created only with the
myisampack utility.
When you use CREATE TABLE or
ALTER TABLE for a table that has no BLOB
or TEXT columns, you can force the table
format to FIXED or
DYNAMIC
with the ROW_FORMAT table option. This
causes
CHAR and VARCHAR
columns to become CHAR for
FIXED
format, or VARCHAR for
DYNAMIC format. See
Section 13.1.5, “CREATE TABLE Syntax”,
for information about
ROW_FORMAT.
Static format is the default for MyISAM
tables. It is used when the table contains no variable-length columns
(VARCHAR,
VARBINARY, BLOB,
or
TEXT). Each row is stored using a fixed
number of bytes.
Of the three MyISAM storage formats,
static format is the simplest and most secure (least subject to
corruption). It is also the fastest of the on-disk formats due to
the ease with which rows in the data file can be found on disk: To
look up a row based on a row number in the index, multiply the row
number by the row length to calculate the row position. Also, when
scanning a table, it is very easy to read a constant number of rows
with each disk read operation.
The security is evidenced if your computer crashes while the MySQL
server is writing to a fixed-format
MyISAM file. In this case,
myisamchk can easily
determine where each row starts and ends, so it can usually reclaim
all rows except the partially written one. Note that
MyISAM
table indexes can always be reconstructed based on the data rows.
Static-format tables have these characteristics:
CHAR and BINARY
columns are space-padded to the column width. This is also true
for NUMERIC and
DECIMAL columns.
Very quick.
Easy to cache.
Easy to reconstruct after a crash, because rows are located in
fixed positions.
Reorganization is unnecessary unless you delete a huge number of
rows and want to return free disk space to the operating system.
To do this, use OPTIMIZE TABLE or
myisamchk -r.
Usually require more disk space than dynamic-format tables.
14.1.3.2. Dynamic Table Characteristics
Dynamic storage format is used if a MyISAM
table contains any variable-length columns (VARCHAR,
VARBINARY,
BLOB, or TEXT),
or if the table was created with the
ROW_FORMAT=DYNAMIC table option.
Dynamic format is a little more complex than static format because
each row has a header that indicates how long it is. A row can
become fragmented (stored in non-contiguous pieces) when it is made
longer as a result of an update.
You can use OPTIMIZE TABLE or
myisamchk -r to
defragment a table. If you have fixed-length columns that you access
or change frequently in a table that also contains some
variable-length columns, it might be a good idea to move the
variable-length columns to other tables just to avoid fragmentation.
Dynamic-format tables have these characteristics:
All string columns are dynamic except those with a length less
than four.
Each row is preceded by a bitmap that indicates which columns
contain the empty string (for string columns) or zero (for
numeric columns). Note that this does not include columns that
contain NULL
values. If a string column has a length of zero after trailing
space removal, or a numeric column has a value of zero, it is
marked in the bitmap and not saved to disk. Non-empty strings
are saved as a length byte plus the string contents.
Much less disk space usually is required than for fixed-length
tables.
Each row uses only as much space as is required. However, if a row
becomes larger, it is split into as many pieces as are required,
resulting in row fragmentation. For example, if you update a row
with information that extends the row length, the row becomes
fragmented. In this case, you may have to run
OPTIMIZE TABLE or
myisamchk -r from
time to time to improve performance. Use
myisamchk -ei
to obtain table statistics.
More difficult than static-format tables to reconstruct after a
crash, because rows may be fragmented into many pieces and links
(fragments) may be missing.
The expected row length for dynamic-sized rows is calculated using
the following expression:
3
+ (number of columns + 7) / 8
+ (number of char columns)
+ (packed size of numeric columns)
+ (length of strings)
+ (number of NULL columns + 7) / 8
There is a penalty of 6 bytes for each link. A dynamic row is
linked whenever an update causes an enlargement of the row. Each
new link is at least 20 bytes, so the next enlargement probably
goes in the same link. If not, another link is created. You can
find the number of links using
myisamchk -ed. All links may be removed with
OPTIMIZE TABLE or
myisamchk -r.
14.1.3.3. Compressed Table Characteristics
Compressed storage format is a read-only format that is generated with
the myisampack tool.
All MySQL distributions as of version 3.23.19 include
myisampack by default.
(This version is when MySQL was placed under the GPL.) For earlier
versions,
myisampack was included
only with licenses or support agreements, but the server still can
read tables that were compressed with
myisampack. Compressed tables can be uncompressed
with
myisamchk. (For the
ISAM
storage engine, compressed tables can be created with
pack_isam and
uncompressed with
isamchk.)
Compressed tables have the following characteristics:
Compressed tables take very little disk space. This minimizes disk
usage, which is helpful when using slow disks (such as CD-ROMs).
Each row is compressed separately, so there is very little access
overhead. The header for a row takes up one to three bytes
depending on the biggest row in the table. Each column is
compressed differently. There is usually a different Huffman
tree for each column. Some of the compression types are:
Suffix space compression.
Prefix space compression.
Numbers with a value of zero are stored using one bit.
If values in an integer column have a small range, the column
is stored using the smallest possible type. For example, a
BIGINT column (eight bytes) can be stored as a
TINYINT
column (one byte) if all its values are in the range from
-128 to
127.
If a column has only a small set of possible values, the data
type is converted to ENUM.
A column may use any combination of the preceding compression
types.
Can be used for fixed-length or dynamic-length rows.
The file format that MySQL uses to store data has been extensively
tested, but there are always circumstances that may cause database
tables to become corrupted. The following discussion describes how this
can happen and how to handle it.
14.1.4.1. Corrupted MyISAM Tables
Even though the MyISAM table format is
very reliable (all changes to a table made by an SQL statement are
written before the statement returns), you can still get corrupted
tables if any of the following events occur:
The mysqld process
is killed in the middle of a write.
An unexpected computer shutdown occurs (for example, the computer
is turned off).
Hardware failures.
You are using an external program (such as
myisamchk) to modify
a table that is being modified by the server at the same time.
A software bug in the MySQL or MyISAM
code.
Typical symptoms of a corrupt table are:
You get the following error while selecting data from the table:
Incorrect key file for table: '...'. Try to repair it
Queries don't find rows in the table or return incomplete results.
If your tables become corrupted frequently, you should try to
determine why this is happening. The most important thing to know is
whether the table became corrupted as a result of a server crash.
You can verify this easily by looking for a recent
restarted mysqld message in the error log. If there is such a
message, it is likely that table corruption is a result of the
server dying. Otherwise, corruption may have occurred during normal
operation. This is a bug. You should try to create a reproducible
test case that demonstrates the problem. See
Section A.4.2, “What to Do If MySQL Keeps Crashing”, and
Section E.1.6, “Making a Test Case If You Experience Table
Corruption”.
14.1.4.2. Problems from Tables Not Being Closed Properly
Each MyISAM index file (.MYI
file) has a counter in the header that can be used to check whether
a table has been closed properly. If you get the following warning
from CHECK TABLE or
myisamchk, it means that this counter has gone out
of sync:
clients are using or haven't closed the table properly
This warning doesn't necessarily mean that the table is corrupted, but
you should at least check the table.
The counter works as follows:
The first time a table is updated in MySQL, a counter in the
header of the index files is incremented.
The counter is not changed during further updates.
When the last instance of a table is closed (because a
FLUSH TABLES operation was performed
or because there is no room in the table cache), the counter is
decremented if the table has been updated at any point.
When you repair the table or check the table and it is found to be
okay, the counter is reset to zero.
To avoid problems with interaction with other processes that might
check the table, the counter is not decremented on close if it
was zero.
In other words, the counter can become incorrect only under these
conditions:
A MyISAM table is copied without
first issuing LOCK TABLES and
FLUSH TABLES.
MySQL has crashed between an update and the final close. (Note
that the table may still be okay, because MySQL always issues
writes for everything between each statement.)
A table was modified by myisamchk
--recover or
myisamchk --update-state at the same time that
it was in use by mysqld.
Multiple mysqld
servers are using the table and one server performed a
REPAIR TABLE or CHECK TABLE
on the table while it was in use by another server. In this
setup, it is safe to use CHECK TABLE,
although you might get the warning from other servers. However,
REPAIR TABLE should be avoided because when one server
replaces the data file with a new one, this is not known to the
other servers.
InnoDB provides MySQL with a transaction-safe
(ACID compliant) storage engine that has
commit, rollback, and crash recovery capabilities.
InnoDB does locking on the row level and also
provides an Oracle-style consistent non-locking read in
SELECT statements. These features increase
multi-user concurrency and performance. There is no need for lock
escalation in InnoDB because row-level
locks fit in very little space. InnoDB also
supports
FOREIGN KEY constraints. You can freely mix
InnoDB tables with tables from other MySQL
storage engines, even within the same statement.
InnoDB has been designed for maximum
performance when processing large data volumes. Its CPU efficiency is
probably not matched by any other disk-based relational database engine.
Fully integrated with MySQL Server, the InnoDB
storage engine maintains its own buffer pool for caching data and indexes
in main memory. InnoDB stores its tables
and indexes in a tablespace, which may consist of several files (or raw
disk partitions). This is different from, for example,
MyISAM tables where each table is stored using separate files.
InnoDB tables can be of any size even on operating systems where
file size is limited to 2GB.
InnoDB is included in binary distributions by
default as of MySQL 4.0. For information about
InnoDB support in MySQL 3.23, see
Section 14.2.3, “InnoDB in MySQL 3.23”.
Starting from MySQL 4.1.5, the improved Windows installer makes
InnoDB the MySQL default storage engine on Windows.
InnoDB is used in production at numerous
large database sites requiring high performance. The famous Internet
news site Slashdot.org runs on InnoDB.
Mytrix, Inc. stores over 1TB of data in InnoDB,
and another site handles an average load of 800 inserts/updates per
second in InnoDB.
Contact information for Innobase Oy, producer of the
InnoDB engine:
Web site: http://www.innodb.com/
Email: <sales@innodb.com>
Phone: +358-9-6969 3250 (office)
+358-40-5617367 (mobile)
Innobase Oy Inc.
World Trade Center Helsinki
Aleksanterinkatu 17
P.O.Box 800
00101 Helsinki
Finland
14.2.3. InnoDB in MySQL 3.23
Beginning with MySQL 4.0, InnoDB is enabled
by default, so the following information applies only to MySQL 3.23.
InnoDB tables are included in the MySQL
source distribution starting from 3.23.34a and are activated in the
MySQL-Max binaries of the 3.23 series. For Windows, the MySQL-Max
binaries are included in the standard distribution.
If you have downloaded a binary version of MySQL that includes support for
InnoDB, simply follow the instructions of the MySQL manual for
installing a binary version of MySQL. If you have MySQL 3.23 installed,
the simplest way to install MySQL-Max is to replace the executable
mysqld server with the
corresponding executable from the MySQL-Max distribution. MySQL and
MySQL-Max differ only in the server executable. See
Section 2.8, “Installing MySQL on Other Unix-Like Systems”, and
Section 5.3, “The mysqld-max
Extended MySQL Server”.
To use InnoDB tables with MySQL 3.23, you
must specify configuration parameters in the
[mysqld] section of the
my.cnf option file. On Windows, you can use
my.ini instead. If you do not configure
InnoDB in the option file,
InnoDB does not start. (From MySQL 4.0 on,
InnoDB uses default parameters if you do not
specify any. However, to get best performance, it is still recommended
that you use parameters appropriate for your system, as discussed in
Section 14.2.4, “InnoDB Configuration”.)
In MySQL 3.23, you must specify at the minimum an
innodb_data_file_path value to configure the
InnoDB data files. For example, to configure
InnoDB to use a single 500MB data file, place
the following setting in the [mysqld]
section of your option file:
[mysqld]
innodb_data_file_path=ibdata1:500M
InnoDB creates the
ibdata1
file in the MySQL data directory by default. To specify the location
explicitly, specify an
innodb_data_home_dir setting. See
Section 14.2.4, “InnoDB Configuration”.
From MySQL 4.0 on, the InnoDB storage engine
is enabled by default. If you don't want to use
InnoDB tables, you can add the
skip-innodb option to your MySQL option file.
Note:
InnoDB
provides MySQL with a transaction-safe (ACID
compliant) storage engine that has commit, rollback, and crash recovery
capabilities. However, it cannot do so
if the underlying operating system or hardware does not work as
advertised. Many operating systems or disk subsystems may delay or
reorder write operations to improve performance. On some operating
systems, the very system call that should wait until all unwritten data
for a file has been flushed —
fsync() — might actually return before the
data has been flushed to stable storage. Because of this, an operating
system crash or a power outage may destroy recently committed data, or
in the worst case, even corrupt the database because of write operations
having been reordered. If data integrity is important to you, you should
perform some “pull-the-plug” tests before
using anything in production. On Mac OS X 10.3 and up,
InnoDB
uses a special fcntl() file flush method.
Under Linux, it is advisable to disable the
write-back cache.
On ATAPI hard disks, a command such hdparm -W0
/dev/hda may work to disable the write-back cache.
Beware that some drives or disk controllers may
be unable to disable the write-back cache.
Two important disk-based resources managed by the
InnoDB storage engine are its tablespace data
files and its log files.
Note: If you specify no
InnoDB configuration options, MySQL 4.0 and
above create an auto-extending 10MB data file named
ibdata1 and two 5MB log files named
ib_logfile0 and
ib_logfile1 in the MySQL data directory. (In
MySQL 4.0.0 and 4.0.1, the data file is 64MB and not auto-extending.) In
MySQL 3.23, InnoDB does not start if you
provide no configuration options. To get good performance, you should
explicitly provide
InnoDB parameters as discussed in the
following examples. Naturally, you should edit the settings to suit your
hardware and requirements.
To set up the InnoDB tablespace files, use
the
innodb_data_file_path option in the
[mysqld] section of the
my.cnf option file. On Windows, you can use
my.ini instead. The value of
innodb_data_file_path should be a list of one
or more data file specifications. If you name more than one data file,
separate them by semicolon (‘;’)
characters:
This setting configures a single 10MB data file named
ibdata1 that is auto-extending. No location
for the file is given, so by default, InnoDB
creates it in the MySQL data directory.
Sizes are specified using M or
G suffix letters to indicate units of MB or
GB.
A tablespace containing a fixed-size 50MB data file named
ibdata1 and a 50MB auto-extending file named
ibdata2 in the data directory can be
configured like this:
The autoextend attribute and those following
can be used only for the last data file in the
innodb_data_file_path line.
autoextend is available starting from MySQL
3.23.50 and 4.0.2.
If you specify the autoextend option for the
last data file, InnoDB extends the data
file if it runs out of free space in the tablespace. The increment is
8MB at a time by default. It can be modified by changing the
innodb_autoextend_increment system variable.
InnoDB is not aware of the filesystem maximum
file size, so be cautious on filesystems where the maximum file size is
a small value such as 2GB. To specify a maximum size for an
auto-extending data file, use the max
attribute. The following configuration allows
ibdata1 to grow up to a limit of 500MB:
InnoDB creates tablespace files in the MySQL
data directory by default. To specify a location explicitly, use the
innodb_data_home_dir option. For example, to use two files named
ibdata1 and
ibdata2 but create them in the
/ibdata directory, configure
InnoDB like this:
Note:
InnoDB
does not create directories, so make sure that the
/ibdata directory exists before you start
the server. This is also true of any log file directories that you
configure. Use the Unix or DOS mkdir
command to create any necessary directories.
InnoDB forms the directory path for each data
file by textually concatenating the value of
innodb_data_home_dir to the data file name,
adding a pathname separator (slash or backslash) between values if
necessary. If the innodb_data_home_dir
option is not mentioned in my.cnf at all,
the default value is the “dot” directory
./, which means the MySQL data directory.
(The MySQL server changes its current working directory to its data
directory when it begins executing.)
If you specify innodb_data_home_dir as an
empty string, you can specify absolute paths for the data files listed
in the innodb_data_file_path value. The
following example is equivalent to the preceding one:
A simple my.cnf
example. Suppose that you have a computer with 128MB RAM
and one hard disk. The following example shows possible configuration
parameters in my.cnf or
my.ini for InnoDB.
The example assumes the use of MySQL-Max 3.23.50 or later or MySQL 4.0.2
or later because it uses the autoextend
attribute. The example suits most users, both on Unix and Windows, who do
not want to distribute InnoDB data files
and log files onto several disks. It creates an auto-extending data file
ibdata1 and two
InnoDB log files
ib_logfile0 and
ib_logfile1 in the MySQL data directory.
Also, the small archived InnoDB log file
ib_arch_log_0000000000 that
InnoDB creates automatically ends up in the
data directory.
[mysqld]
# You can write your other MySQL server options here
# ...
# Data files must be able to hold your data and indexes.
# Make sure that you have enough free disk space.
innodb_data_file_path = ibdata1:10M:autoextend
#
# Set buffer pool size to 50-80% of your computer's memory
set-variable = innodb_buffer_pool_size=70M
set-variable = innodb_additional_mem_pool_size=10M
#
# Set the log file size to about 25% of the buffer pool size
set-variable = innodb_log_file_size=20M
set-variable = innodb_log_buffer_size=8M
#
innodb_flush_log_at_trx_commit=1
Make sure that the MySQL server has the proper access rights to create
files in the data directory. More generally, the server must have access
rights in any directory where it needs to create data files or log
files.
Note that data files must be less than 2GB in some filesystems. The
combined size of the log files must be less than 4GB. The combined size
of data files must be at least 10MB.
When you create an InnoDB tablespace for the
first time, it is best that you start the MySQL server from the command
prompt. InnoDB then prints the information
about the database creation to the screen, so you can see what is
happening. For example, on Windows, if
mysqld is located in
C:\Program Files\MySQL\MySQL Server 4.1\bin, you can start it
like this:
C:\> "C:\Program Files\MySQL\MySQL Server 4.1\bin\mysqld" --console
If you do not send server output to the screen, check the server's error
log to see what InnoDB prints during the
startup process.
You can place InnoDB options in the
[mysqld] group of any option file that your
server reads when it starts. The locations for option files are
described in
Section 4.3.2, “Using Option Files”.
If you installed MySQL on Windows using the installation and configuration
wizards, the option file will be the
my.ini file located in your MySQL
installation directory. See
Section 2.3.4.14, “The Location of the my.ini File”.
If your PC uses a boot loader where the C:
drive is not the boot drive, your only option is to use the
my.ini file in your Windows directory
(typically C:\WINDOWS or
C:\WINNT). You can use the
SET command at the command prompt in a
console window to print the value of WINDIR:
C:\> SET WINDIR
windir=C:\WINDOWS
If you want to make sure that mysqld
reads options only from a specific file, you can use the
--defaults-file option as the first option on
the command line when starting the server:
mysqld --defaults-file=your_path_to_my_cnf
An advanced my.cnf
example. Suppose that you have a Linux computer with 2GB
RAM and three 60GB hard disks at directory paths
/, /dr2 and
/dr3. The following example shows possible
configuration parameters in my.cnf for
InnoDB.
[mysqld]
# You can write your other MySQL server options here
# ...
innodb_data_home_dir =
#
# Data files must be able to hold your data and indexes
innodb_data_file_path = /ibdata/ibdata1:2000M;/dr2/ibdata/ibdata2:2000M:autoextend
#
# Set buffer pool size to 50-80% of your computer's memory,
# but make sure on Linux x86 total memory usage is < 2GB
set-variable = innodb_buffer_pool_size=1G
set-variable = innodb_additional_mem_pool_size=20M
innodb_log_group_home_dir = /dr3/iblogs
#
# innodb_log_arch_dir must be the same as innodb_log_group_home_dir
# (starting from 4.0.6, you can omit it)
innodb_log_arch_dir = /dr3/iblogs
set-variable = innodb_log_files_in_group=2
#
# Set the log file size to about 25% of the buffer pool size
set-variable = innodb_log_file_size=250M
set-variable = innodb_log_buffer_size=8M
#
innodb_flush_log_at_trx_commit=1
set-variable = innodb_lock_wait_timeout=50
#
# Uncomment the next lines if you want to use them
#set-variable = innodb_thread_concurrency=5
In some cases, database performance improves the if all data is not placed
on the same physical disk. Putting log files on a different disk from
data is very often beneficial for performance. The example illustrates
how to do this. It places the two data files on different disks and
places the log files on the third disk. InnoDB
fills the tablespace beginning with the first data file. You can also
use raw disk partitions (raw devices) as InnoDB
data files, which may speed up I/O. See
Section 14.2.4.2, “Using Raw Devices for the Shared Tablespace”.
Warning: On 32-bit GNU/Linux
x86, you must be careful not to set memory usage too high.
glibc may allow the process heap to grow over
thread stacks, which crashes your server. It is a risk if the value of
the following expression is close to or exceeds 2GB:
Each thread uses a stack (often 2MB, but only 256KB in MySQL AB binaries)
and in the worst case also uses
sort_buffer_size + read_buffer_size
additional memory.
How to tune other
mysqld
server parameters? The following values are typical and
suit most users:
[mysqld]
skip-external-locking
set-variable = max_connections=200
set-variable = read_buffer_size=1M
set-variable = sort_buffer_size=1M
#
# Set key_buffer to 5 - 50% of your RAM depending on how much
# you use MyISAM tables, but keep key_buffer_size + InnoDB
# buffer pool size < 80% of your RAM
set-variable = key_buffer_size=...
14.2.4.1. Using Per-Table Tablespaces
Note: There is a known bug in
versions prior to 4.1.8 that manifests itself if you specify
innodb_file_per_table in
my.cnf. If you shut down
mysqld, then records may
disappear from the secondary indexes of a table. See
Bug#7496 for more information and workarounds. This is fixed in
4.1.9, but another bug (Bug#8021)
bit the Windows version in 4.1.9, and in the Windows version of 4.1.9
you must put the line
innodb_flush_method=unbuffered to your
my.cnf or my.ini
to get mysqld to work.
Starting from MySQL 4.1.1, you can store each
InnoDB table and its indexes in its own
file. This feature is called “multiple tablespaces”
because in effect each table has its own tablespace.
Using multiple tablespaces can be beneficial to users who want to move
specific tables to separate physical disks or who wish to restore
backups of single tables quickly without interrupting the use of the
remaining InnoDB tables.
If you need to downgrade to 4.0, you must make table dumps and re-create
the whole InnoDB tablespace. If you have
not created new InnoDB tables under MySQL
4.1.1 or later, and need to downgrade quickly, you can also do a direct
downgrade to the MySQL 4.0.18 or later in the 4.0 series. Before doing
the direct downgrade to 4.0.x, you have to end all client connections to
the mysqld
server that is to be downgraded, and let it run the purge and insert
buffer merge operations to completion, so that
SHOW INNODB STATUS shows the main thread in
the state waiting for server activity. Then
you can shut down mysqld
and start 4.0.18 or later in the 4.0 series.
You can enable multiple tablespaces by adding a line to the
[mysqld] section of
my.cnf:
[mysqld]
innodb_file_per_table
After restarting the server, InnoDB stores
each newly created table into its own file
tbl_name.ibd
in the database directory where the table belongs. This is similar to
what the MyISAM storage engine does, but
MyISAM divides the table into a data file
tbl_name.MYD
and the index file
tbl_name.MYI.
For InnoDB, the data and the indexes are
stored together in the .ibd file. The
tbl_name.frm
file is still created as usual.
If you remove the innodb_file_per_table
line from my.cnf and restart the server,
InnoDB creates tables inside the shared
tablespace files again.
innodb_file_per_table affects only table
creation, not access to existing tables. If you start the server with
this option, new tables are created using
.ibd files, but you can still access
tables that exist in the shared tablespace. If you remove the option and
restart the server, new tables are created in the shared tablespace, but
you can still access any tables that were created using multiple
tablespaces.
Note:
InnoDB
always needs the shared tablespace because it puts its internal data
dictionary and undo logs there. The
.ibd files are not sufficient for
InnoDB to operate.
Note: You cannot freely move
.ibd files between database directories as
you can with MyISAM table files. This is
because the table definition that is stored in the
InnoDB shared tablespace includes the
database name, and because InnoDB must
preserve the consistency of transaction IDs and log sequence numbers.
To move an .ibd file and the associated
table from one database to another, use a RENAME
TABLE statement:
RENAME TABLE db1.tbl_name TO db2.tbl_name;
If you have a “clean” backup of an
.ibd file, you can restore it to the MySQL
installation from which it originated as follows:
Issue this ALTER TABLE statement:
ALTER TABLE tbl_name DISCARD TABLESPACE;
Caution: This statement
deletes the current .ibd file.
Put the backup .ibd file back in the
proper database directory.
Issue this ALTER TABLE statement:
ALTER TABLE tbl_name IMPORT TABLESPACE;
In this context, a “clean”
.ibd file backup means:
There are no uncommitted modifications by transactions in the
.ibd file.
There are no unmerged insert buffer entries in the
.ibd file.
Purge has removed all delete-marked index records from the
.ibd file.
mysqld has flushed all
modified pages of the .ibd file from
the buffer pool to the file.
You can make a clean backup .ibd file
using the following method:
Stop all activity from the mysqld
server and commit all transactions.
Wait until SHOW INNODB STATUS shows
that there are no active transactions in the database, and the main
thread status of InnoDB is
Waiting for server activity. Then you
can make a copy of the .ibd file.
Another method for making a clean copy of an
.ibd file is to use the commercial
InnoDB Hot Backup tool:
Use InnoDB Hot Backup
to back up the
InnoDB installation.
Start a second mysqld
server on the backup and let it clean up the
.ibd
files in the backup.
14.2.4.2. Using Raw Devices for the Shared Tablespace
Starting from MySQL 3.23.41, you can use raw disk partitions as data
files in the shared tablespace. By using a raw disk, you can perform
non-buffered I/O on Windows and on some Unix systems without filesystem
overhead, which might improve performance.
When you create a new data file, you must put the keyword
newraw immediately after the data file size
in innodb_data_file_path. The partition
must be at least as large as the size that you specify. Note that 1MB in
InnoDB is 1024 × 1024 bytes, whereas 1MB in disk specifications
usually means 1,000,000 bytes.
The next time you start the server, InnoDB
notices the newraw keyword and initializes
the new partition. However, do not create or change any
InnoDB tables yet. Otherwise, when you next
restart the server, InnoDB reinitializes
the partition and your changes are lost. (Starting from MySQL 3.23.44,
as a safety measure InnoDB prevents users
from modifying data when any partition with
newraw is specified.)
After InnoDB has initialized the new
partition, stop the server, change newraw
in the data file specification to raw:
The //./ corresponds to the Windows syntax
of \\.\ for accessing physical drives.
When you use raw disk partitions, be sure that they have permissions
that allow read and write access by the account used for running the
MySQL server.
14.2.5. InnoDB Startup Options and
System Variables
This section describes the InnoDB-related
command options and system variables. System variables that take a
numeric value can be specified as
--var_name=value
on the command line or as
var_name=value
in option files. Many of the system variables can be changed at runtime
(see
Section 5.2.3.2, “Dynamic System Variables”). (Before MySQL 4.0.2,
system variable values should be specified using
--set-variable syntax.) For more information
on specifying options and system variables, see
Section 4.3, “Specifying Program Options”.
InnoDB command options:
--innodb
Enables the InnoDB storage engine, if the
server was compiled with InnoDB
support. Use --skip-innodb to disable
InnoDB.
--innodb_status_file
Causes InnoDB to create a file named
<datadir>/innodb_status.<pid>
in the MySQL data directory. InnoDB
periodically writes the output of SHOW ENGINE
INNODB STATUS to this file. This option is available as of
MySQL 4.0.21.
InnoDB system variables:
innodb_additional_mem_pool_size
The size in bytes of a memory pool InnoDB
uses to store data dictionary information and other internal data
structures. The more tables you have in your application, the more
memory you need to allocate here. If
InnoDB runs out of memory in this pool,
it starts to allocate memory from the operating system, and writes
warning messages to the MySQL error log. The default value is 1MB.
innodb_autoextend_increment
The increment size (in MB) for extending the size of an auto-extending
tablespace when it becomes full. The default value is 8. This
variable is available starting from MySQL 4.0.24 and 4.1.5. As of
MySQL 4.0.24 and 4.1.6, it can be changed at runtime as a global
system variable.
innodb_buffer_pool_awe_mem_mb
The size of the buffer pool (in MB), if it is placed in the AWE
memory. This is relevant only in 32-bit Windows. If your 32-bit
Windows operating system supports more than 4GB memory, using
so-called “Address Windowing Extensions,”
you can allocate the InnoDB buffer pool
into the AWE physical memory using this variable. The maximum
possible value for this variable is 63000. If it is greater than 0,
innodb_buffer_pool_size is the window in the 32-bit address
space of
mysqld where
InnoDB maps that AWE memory. A good value for
innodb_buffer_pool_size is 500MB. This
variable is available as of MySQL 4.1.0.
To take advantage of AWE memory, you will need to recompile MySQL
yourself. The current project settings needed for doing this can be
found in the
innobase/os/os0proj.c source file.
innodb_buffer_pool_size
The size in bytes of the memory buffer
InnoDB uses to cache data and indexes of
its tables. The larger you set this value, the less disk I/O is
needed to access data in tables. On a dedicated database server, you
may set this to up to 80% of the machine physical memory size.
However, do not set it too large because competition for physical
memory might cause paging in the operating system.
innodb_data_file_path
The paths to individual data files and their sizes. The full directory
path to each data file is acquired by concatenating
innodb_data_home_dir to each path
specified here. The file sizes are specified in MB or GB (1024MB) by
appending M or G
to the size value. The sum of the sizes of the files must be at
least 10MB. On some operating systems, files must be less than 2GB.
If you do not specify
innodb_data_file_path, the default
behavior starting from 4.0 is to create a single 10MB auto-extending
data file named ibdata1. Starting from
3.23.44, you can set the file size larger than 4GB on those
operating systems that support big files. You can also use raw disk
partitions as data files. See
Section 14.2.4.2, “Using Raw Devices for the Shared Tablespace”.
innodb_data_home_dir
The common part of the directory path for all
InnoDB data files. If you do not set this
value, the default is the MySQL data directory. You can specify this
also as an empty string, in which case you can use absolute file
paths in
innodb_data_file_path.
innodb_fast_shutdown
If you set this variable to 0, InnoDB
does a full purge and an insert buffer merge before a shutdown.
These operations can take minutes, or even hours in extreme cases.
If you set this variable to 1,
InnoDB skips these operations at
shutdown. The default value is 1 starting from 3.23.50.
innodb_file_io_threads
The number of file I/O threads in InnoDB.
Normally, this should be left at the default value of 4, but disk
I/O on Windows may benefit from a larger number. On Unix, increasing
the number has no effect; InnoDB
always uses the default value. This variable is available as of MySQL
3.23.37.
innodb_file_per_table
NOTE: A bug in versions <=
4.1.8 if you specify innodb_file_per_table
in my.cnf! If you shut down
mysqld, then records may
disappear from the secondary indexes of a table. See
Bug#7496 for more information and workarounds. This is fixed in
4.1.9, but another bug (Bug#8021)
bit the Windows version in 4.1.9, and in the Windows version of
4.1.9 you must put the line
innodb_flush_method=unbuffered in your
my.cnf or my.ini
to get mysqld to work.
If this variable is enabled, InnoDB
creates each new table using its own .ibd
file for storing data and indexes, rather than in the shared
tablespace. The default is to create tables in the shared
tablespace. See
Section 14.2.4.1, “Using Per-Table Tablespaces”. This variable
is available as of MySQL 4.1.1.
innodb_flush_log_at_trx_commit
When innodb_flush_log_at_trx_commit is
set to 0, the log buffer is written out to the log file once per
second and the flush to disk operation is performed on the log file,
but nothing is done at a transaction commit. When this value is 1
(the default), the log buffer is written out to the log file at each
transaction commit and the flush to disk operation is performed on
the log file. When set to 2, the log buffer is written out to the
file at each commit, but the flush to disk operation is not
performed on it. However, the flushing on the log file takes place
once per second also when the value is 2. Note that the
once-per-second flushing is not 100% guaranteed to happen every
second, due to process scheduling issues.
The default value of this variable is 1, which is the value that is
required for ACID compliance. You can achieve better performance by
setting the value different from 1, but then you can lose at most
one second worth of transactions in a crash. If you set the value to
0, then any
mysqld process crash can
erase the last second of transactions. If you set the value to 2,
then only an operating system crash or a power outage can erase the
last second of transactions. However, InnoDB's
crash recovery is not affected and thus crash recovery does work
regardless of the value. Note that many operating systems and some
disk hardware fool the flush-to-disk operation. They may tell
mysqld that the flush has taken place, even though
it has not. Then the durability of transactions is not guaranteed
even with the setting 1, and in the worst case a power outage can
even corrupt the
InnoDB database. Using a battery-backed
disk cache in the SCSI disk controller or in the disk itself speeds
up file flushes, and makes the operation safer. You can also try
using the Unix command hdparm
to disable the caching of disk writes in hardware caches, or use
some other command specific to the hardware vendor. The default
value of this variable is 1 (prior to MySQL 4.0.13, the default is
0).
Note: For the greatest possible durability and consistency in a
replication setup using InnoDB with
transactions, you should use
innodb_flush_log_at_trx_commit=1,
sync_binlog=1, and
innodb_safe_binlog in your master server
my.cnf file.
innodb_flush_method
If set to fdatasync (the default),
InnoDB uses fsync()
to flush both the data and log files. If set to
O_DSYNC, InnoDB
uses
O_SYNC to open and flush the log files,
but uses fsync() to flush the data
files. If
O_DIRECT is specified (available on some
GNU/Linux versions starting from MySQL 4.0.14),
InnoDB uses
O_DIRECT to open the data files, and uses
fsync() to flush both the data and log files. Note that
starting from MySQL 3.23.41, InnoDB
uses
fsync() instead of
fdatasync(), and it does not use
O_DSYNC by default because there have
been problems with it on many varieties of Unix. This variable is
relevant only for Unix. On Windows, the flush method is always
async_unbuffered and cannot be changed.
This variable is available as of MySQL 3.23.40.
innodb_force_recovery
The crash recovery mode. Warning: This variable should be set greater
than 0 only in an emergency situation when you want to dump your
tables from a corrupt database! Possible values are from 1 to 6. The
meanings of these values are described in
Section 14.2.9.1, “Forcing InnoDB
Recovery”. As a safety measure,
InnoDB prevents any changes to its data
when this variable is greater than 0. This variable is available
starting from MySQL 3.23.44.
innodb_lock_wait_timeout
The timeout in seconds an InnoDB
transaction may wait for a lock before being rolled back.
InnoDB automatically detects transaction
deadlocks in its own lock table and rolls back the transaction.
Beginning with MySQL 4.0.20 and 4.1.2,
InnoDB notices locks set using the
LOCK TABLES statement. Before that, if
you use the LOCK TABLES statement, or
other transaction-safe storage engines than
InnoDB in the same transaction, a
deadlock may arise that InnoDB cannot
notice. In cases like this, the timeout is useful to resolve the
situation. The default is 50 seconds.
innodb_locks_unsafe_for_binlog
This variable controls next-key locking in
InnoDB searches and index scans. By
default, this variable is 0 (disabled), which means that next-key
locking is enabled.
Normally, InnoDB uses an algorithm called
next-key locking.
InnoDB performs row-level locking in such
a way that when it searches or scans a table index, it sets shared
or exclusive locks on any index records it encounters. Thus, the
row-level locks are actually index record locks. The locks that
InnoDB sets on index records also affect the “gap”
preceding that index record. If a user has a shared or exclusive
lock on record
R in an index, another user
cannot insert a new index record immediately before
R
in the order of the index. Enabling this variable causes
InnoDB not to use next-key locking in
searches or index scans. Next-key locking is still used to ensure
foreign key constraints and duplicate key checking. Note that
enabling this variable may cause phantom problems: Suppose that you
want to read and lock all children from the
child table with an identifier value
larger than 100, with the intention of updating some column in the
selected rows later:
SELECT * FROM child WHERE id > 100 FOR UPDATE;
Suppose that there is an index on the id
column. The query scans that index starting from the first record
where id is larger than 100. If the
locks set on the index records do not lock out inserts made in the
gaps, another client can insert a new row into the table. If you
execute the same SELECT within the same
transaction, you see a new row in the result set returned by the
query. This also means that if new items are added to the database,
InnoDB does not guarantee serializability Therefore, if this
variable is enabled
InnoDB guarantees at most isolation level
READ COMMITTED. (Conflict serializability
is still guaranteed.) This variable is available as of MySQL 4.1.4.
innodb_log_arch_dir
The directory where fully written log files would be archived if we
used log archiving. The value of this variable should currently be
set the same as
innodb_log_group_home_dir. Starting from
MySQL 4.0.6, there is no need to set this variable.
innodb_log_archive
Whether to log InnoDB archive files. This
variable is unused. Recovery from a backup is done by MySQL using
its own log files, so there is no need to archive
InnoDB log files. The default for this
variable is 0.
innodb_log_buffer_size
The size in bytes of the buffer that InnoDB
uses to write to the log files on disk. Sensible values range from 1MB
to 8MB. The default is 1MB. A large log buffer allows large
transactions to run without a need to write the log to disk before
the transactions commit. Thus, if you have big transactions, making
the log buffer larger saves disk I/O.
innodb_log_file_size
The size in bytes of each log file in a log group. The combined size
of log files must be less than 4GB on 32-bit computers. The default
is 5MB. Sensible values range from 1MB to 1/N-th
of the size of the buffer pool, where
N is the number of log files in the group. The larger
the value, the less checkpoint flush activity is needed in the
buffer pool, saving disk I/O. But larger log files also mean that
recovery is slower in case of a crash.
innodb_log_files_in_group
The number of log files in the log group.
InnoDB writes to the files in a circular
fashion. The default (and recommended) is 2.
innodb_log_group_home_dir
The directory path to the InnoDB log
files. It must have the same value as
innodb_log_arch_dir. If you do not
specify any InnoDB log variables, the
default is to create two 5MB files names
ib_logfile0
and ib_logfile1 in the MySQL data
directory.
innodb_max_dirty_pages_pct
This is an integer in the range from 0 to 100. The default is 90. The
main thread in InnoDB tries to write
pages from the buffer pool so that the percentage of dirty (not yet
written) pages will not exceed this value. Available starting from
4.0.13 and 4.1.1.
innodb_max_purge_lag
This variable controls how to delay INSERT,
UPDATE and DELETE
operations when the purge operations are lagging (see
Section 14.2.13, “Implementation of Multi-Versioning”). The
default value of this variable is 0, meaning that there are no
delays.
innodb_max_purge_lag is available as of
MySQL 4.0.22 and 4.1.6.
The InnoDB transaction system maintains a
list of transactions that have delete-marked index records by
UPDATE or DELETE
operations. Let the length of this list be
purge_lag. When
purge_lag exceeds
innodb_max_purge_lag, each
INSERT, UPDATE
and
DELETE operation is delayed by ((purge_lag/innodb_max_purge_lag)×10)–5
milliseconds. The delay is computed in the beginning of a purge
batch, every ten seconds. The operations are not delayed if purge
cannot run because of an old consistent read view that could see the
rows to be purged.
A typical setting for a problematic workload might be 1 million,
assuming that our transactions are small, only 100 bytes in size,
and we can allow 100MB of unpurged rows in our tables.
innodb_mirrored_log_groups
The number of identical copies of log groups to keep for the database.
Currently, this should be set to 1.
innodb_open_files
This variable is relevant only if you use multiple tablespaces in
InnoDB. It specifies the maximum number of
.ibd files that
InnoDB can keep open at one time. The
minimum value is 10. The default is 300. This variable is available
as of MySQL 4.1.1.
The file descriptors used for .ibd files
are for InnoDB only. They are
independent of those specified by the
--open-files-limit
server option, and do not affect the operation of the table cache.
Starting from MySQL 4.0.20, and 4.1.2,
InnoDB honors LOCK
TABLES; MySQL does not return from LOCK
TABLE .. WRITE until all other threads have released all
their locks to the table. In MySQL 4.0.19 and before,
InnoDB ignored table locks, which allowed
one to more easily simulate transactions with a combination of
MyISAM and InnoDB