ARCHIVE storage engine produces
special-purpose tables that store large amounts of unindexed data in
a very small footprint.
Table 18.5 ARCHIVE Storage Engine Features
|Backup/point-in-time recovery (Implemented in the server, rather than in the storage engine.)
|Cluster database support
|Yes (Implemented in the server via encryption functions.)
|Foreign key support
|Full-text search indexes
|Geospatial data type support
|Geospatial indexing support
|Replication support (Implemented in the server, rather than in the storage engine.)
|Update statistics for data dictionary
ARCHIVE storage engine is included in MySQL
binary distributions. To enable this storage engine if you build
MySQL from source, invoke CMake with the
To examine the source for the
look in the
storage/archive directory of a
MySQL source distribution.
You can check whether the
ARCHIVE storage engine
is available with the
When you create an
ARCHIVE table, the storage
engine creates files with names that begin with the table name. The
data file has an extension of
.ARN file may appear during optimization
ARCHIVE engine supports
SELECT, but not
UPDATE. It does support
ORDER BY operations,
BLOB columns, and spatial data types
(see Section 13.4.1, “Spatial Data Types”). Geographic spatial
reference systems are not supported. The
engine uses row-level locking.
ARCHIVE engine supports the
AUTO_INCREMENT column attribute. The
AUTO_INCREMENT column can have either a unique or
nonunique index. Attempting to create an index on any other column
results in an error. The
ARCHIVE engine also
AUTO_INCREMENT table option in
CREATE TABLE statements to specify
the initial sequence value for a new table or reset the sequence
value for an existing table, respectively.
ARCHIVE does not support inserting a value into
AUTO_INCREMENT column less than the current
maximum column value. Attempts to do so result in an
ARCHIVE engine ignores
BLOB columns if they are not
requested and scans past them while reading.
ARCHIVE storage engine does not support
Storage: Rows are compressed as
they are inserted. The
ARCHIVE engine uses
zlib lossless data compression (see
http://www.zlib.net/). You can use
OPTIMIZE TABLE to analyze the table
and pack it into a smaller format (for a reason to use
OPTIMIZE TABLE, see later in this
section). The engine also supports
TABLE. There are several types of insertions that are
A bulk insert is visible only after it completes, unless other inserts occur at the same time, in which case it can be seen partially. A
SELECTnever causes a flush of a bulk insert unless a normal insert occurs while it is loading.
Retrieval: On retrieval, rows are
uncompressed on demand; there is no row cache. A
SELECT operation performs a complete
table scan: When a
SELECT occurs, it
finds out how many rows are currently available and reads that
number of rows.
SELECT is performed
as a consistent read. Note that lots of
SELECT statements during insertion
can deteriorate the compression, unless only bulk inserts are used.
To achieve better compression, you can use
OPTIMIZE TABLE or
REPAIR TABLE. The number of rows in
ARCHIVE tables reported by
SHOW TABLE STATUS is always accurate.
See Section 220.127.116.11, “OPTIMIZE TABLE Statement”,
Section 18.104.22.168, “REPAIR TABLE Statement”, and
Section 22.214.171.124, “SHOW TABLE STATUS Statement”.
A forum dedicated to the
ARCHIVEstorage engine is available at https://forums.mysql.com/list.php?112.