Oracle 5.0 Reference Manual page 1297

14.2.9.3. Insert Buffering
It is a common situation in database applications that the primary key is a unique identifier and new
rows are inserted in the ascending order of the primary key. Thus, insertions into the clustered index do
not require random reads from a disk.
On the other hand, secondary indexes are usually nonunique, and insertions into secondary indexes
happen in a relatively random order. This would cause a lot of random disk I/O operations without a
special mechanism used in InnoDB.
If an index record should be inserted into a nonunique secondary index,
the secondary index page is in the buffer pool. If that is the case,
to the index page. If the index page is not found in the buffer pool,
special insert buffer structure. The insert buffer is kept so small that it fits entirely in the buffer pool, and
insertions can be done very fast.
Periodically, the insert buffer is merged into the secondary index trees in the database. Often it is
possible to merge several insertions into the same page of the index tree, saving disk I/O operations. It
has been measured that the insert buffer can speed up insertions into a table up to 15 times.
The insert buffer merging may continue to happen after the inserting transaction has been committed.
In fact, it may continue to happen after a server shutdown and restart (see
Recovery").
InnoDB
Insert buffer merging may take many hours when many secondary indexes must be updated and
many rows have been inserted. During this time, disk I/O will be increased, which can cause significant
slowdown on disk-bound queries. Another significant background I/O operation is the purge thread (see
Section 14.2.8,
14.2.9.4. Adaptive Hash Indexes
If a table fits almost entirely in main memory, the fastest way to perform queries on it is to use hash
indexes.
InnoDB
table. If
InnoDB
The hash index is always built based on an existing B-tree index on the table.
index on a prefix of any length of the key defined for the B-tree, depending on the pattern of searches
that
InnoDB
B-tree index is cached in the buffer pool.
the index that are often accessed.
In a sense,
coming closer to the architecture of main-memory databases.
14.2.9.5. Physical Row Structure
The physical row structure for an
ROW_FORMAT
only the
REDUNDANT
row format, but you can use the
COMPACT
of tables. To check the row format of an
InnoDB
The compact row format decreases row storage space by about 20% at the cost of increasing CPU
use for some operations. If your workload is a typical one that is limited by cache hit rates and disk
speed, compact format is likely to be faster. If the workload is a rare case that is limited by CPU speed,
compact format might be slower.
Rows in
InnoDB
InnoDB
A version of
InnoDB
from a version built for a different page size.
"InnoDB Multi-Versioning").
has a mechanism that monitors index searches made to the indexes defined for a
notices that queries could benefit from building a hash index, it does so automatically.
observes for the B-tree index. A hash index can be partial: It is not required that the whole
tailors itself through the adaptive hash index mechanism to ample main memory,
InnoDB
InnoDB
option used when the table was created. For
row format was available. For MySQL 5.0.3 and later, the default is to use the
tables that use
REDUNDANT
Table and Index Structures
built for one page size cannot use data files or log files
builds hash indexes on demand for those pages of
InnoDB
table depends on the MySQL version and the optional
InnoDB
format to retain compatibility with older versions
REDUNDANT
table use
InnoDB
row format have the following characteristics:
1277
checks whether
InnoDB
does the insertion directly
InnoDB
inserts the record to a
InnoDB
Section 14.2.5.2, "Forcing
can build a hash
InnoDB
tables in MySQL 5.0.3 and earlier,
SHOW TABLE STATUS.