The ARCHIVE storage engine is used for storing
large amounts of data without indexes in a very small footprint.
Table 13.6. ARCHIVE Storage Engine
Features
| Storage limits | None | Transactions | No | Locking granularity | Row |
| MVCC | No | Geospatial datatype support | Yes | Geospatial indexing support | No |
| B-tree indexes | No | Hash indexes | No | Full-text search indexes | No |
| Clustered indexes | No | Data caches | No | Index caches | No |
| Compressed data | Yes | Encrypted data[a] | Yes | Cluster database support | No |
| Replication support[b] | Yes | Foreign key support | No | Backup / point-in-time recovery[c] | Yes |
| Query cache support | Yes | Update statistics for data dictionary | Yes | ||
|
[a] Implemented in the server (via encryption functions), rather than in the storage engine. [b] Implemented in the server, rather than in the storage engine [c] Implemented in the server, rather than in the storage engine | |||||
The ARCHIVE storage engine is included in MySQL
binary distributions. To enable this storage engine if you build
MySQL from source, invoke configure with the
--with-archive-storage-engine option.
To examine the source for the ARCHIVE engine,
look in the storage/archive directory of a
MySQL source distribution.
You can check whether the ARCHIVE storage engine
is available with the SHOW ENGINES
statement.
When you create an ARCHIVE table, the server
creates a table format file in the database directory. The file
begins with the table name and has an .frm
extension. The storage engine creates other files, all having names
beginning with the table name. The data file has an extension of
.ARZ. (Prior to MySQL 5.1.15, a metadata file
with an extension of .ARM is created as well.)
An .ARN file may appear during optimization
operations.
The ARCHIVE engine supports
INSERT and
SELECT, but not
DELETE,
REPLACE, or
UPDATE. It does support
ORDER BY operations,
BLOB columns, and basically all but
spatial data types (see Section 11.13.4.1, “MySQL Spatial Data Types”).
The ARCHIVE engine uses row-level locking.
As of MySQL 5.1.6, the 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
supports the AUTO_INCREMENT table option in
CREATE TABLE and
ALTER TABLE statements to specify the
initial sequence value for a new table or reset the sequence value
for an existing table, respectively.
As of MySQL 5.1.6, the ARCHIVE engine ignores
BLOB columns if they are not
requested and scans past them while reading. Formerly, the following
two statements had the same cost, but as of 5.1.6, the second is
much more efficient than the first:
SELECT a, b, blob_col FROM archive_table; SELECT a, b FROM archive_table;
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 CHECK
TABLE. There are several types of insertions that are
used:
An INSERT statement just pushes
rows into a compression buffer, and that buffer flushes as
necessary. The insertion into the buffer is protected by a lock.
A SELECT forces a flush to occur,
unless the only insertions that have come in were
INSERT DELAYED (those flush as
necessary). See Section 12.2.5.2, “INSERT DELAYED Syntax”.
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 SELECT never 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 or delayed 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 12.5.2.5, “OPTIMIZE TABLE Syntax”,
Section 12.5.2.6, “REPAIR TABLE Syntax”, and
Section 12.5.5.38, “SHOW TABLE STATUS Syntax”.
Additional resources
A forum dedicated to the ARCHIVE storage
engine is available at http://forums.mysql.com/list.php?112.

User Comments
The ARCHIVE type does not support AUTO_INCREMENT columns (MySQL 5.0.45)
Add your own comment.