The world's most popular open source database
The following are known problems with MERGE
tables:
If you use ALTER TABLE to
change a MERGE table to another storage
engine, the mapping to the underlying tables is lost. Instead,
the rows from the underlying MyISAM tables
are copied into the altered table, which then uses the
specified storage engine.
REPLACE does not work as
expected because the MERGE engine cannot
enforce uniqueness over the set of underlying tables. The two
key facts are:
REPLACE can detect unique
key violations only in the underlying table to which it is
going to write (which is determined by
INSERT_METHOD). This differs from
violations in the MERGE table itself.
If REPLACE detects such a
violation, it will only change the corresponding row in
the first underlying table in which the row is present,
whereas a row with the same unique key value may be
present in all underlying tables.
Similar considerations apply for INSERT ... ON
DUPLICATE KEY UPDATE.
MERGE tables do not support partitioning.
That is, you cannot partition a MERGE
table, nor can any of a MERGE table's
underlying MyISAM tables be partitioned.
You cannot use REPAIR TABLE,
OPTIMIZE TABLE,
DROP TABLE,
ALTER TABLE,
DELETE without a
WHERE clause,
TRUNCATE
TABLE, or ANALYZE
TABLE on any of the tables that are mapped into an
open MERGE table. If you do so, the
MERGE table may still refer to the original
table, which yields unexpected results. The easiest way to
work around this deficiency is to ensure that no
MERGE tables remain open by issuing a
FLUSH TABLES
statement prior to performing any of those operations.
The unexpected results include the possibility that the
operation on the MERGE table will report
table corruption. However, if this occurs after operations on
the underlying MyISAM tables such as those
listed in the previous paragraph (REPAIR
TABLE, OPTIMIZE
TABLE, and so forth), the corruption message is
spurious. To deal with this, issue a
FLUSH TABLES
statement after modifying the MyISAM
tables.
DROP TABLE on a table that is
in use by a MERGE table does not work on
Windows because the MERGE storage engine's
table mapping is hidden from the upper layer of MySQL. Windows
does not allow open files to be deleted, so you first must
flush all MERGE tables (with
FLUSH TABLES)
or drop the MERGE table before dropping the
table.
A MERGE table cannot maintain uniqueness
constraints over the entire table. When you perform an
INSERT, the data goes into the
first or last MyISAM table (depending on
the value of the INSERT_METHOD option).
MySQL ensures that unique key values remain unique within that
MyISAM table, but not across all the tables
in the collection.
The INSERT_METHOD table option for a
MERGE table indicates which underlying
MyISAM table to use for inserts into the
MERGE table. However, use of the
AUTO_INCREMENT table option for that
MyISAM table has no effect for inserts into
the MERGE table until at least one row has
been inserted directly into the MyISAM
table.
The definition of the MyISAM tables and the
MERGE table are checked when the tables are
accessed (for example, as part of a
SELECT or
INSERT statement). The checks
ensure that the definitions of the tables and the parent
MERGE table definition match by comparing
column order, types, sizes and associated indexes. If there is
a difference between the tables then an error will be returned
and the statement will fail.
Because these checks take place when the tables are opened, any changes to the definition of a single table, including column changes, column ordering and engine alterations will cause the statement to fail.
The order of indexes in the MERGE table and
its underlying tables should be the same. If you use
ALTER TABLE to add a
UNIQUE index to a table used in a
MERGE table, and then use
ALTER TABLE to add a non-unique
index on the MERGE table, the index
ordering is different for the tables if there was already a
non-unique index in the underlying table. (This happens
because ALTER TABLE puts
UNIQUE indexes before non-unique indexes to
facilitate rapid detection of duplicate keys.) Consequently,
queries on tables with such indexes may return unexpected
results.
If you encounter an error message similar to ERROR
1017 (HY000): Can't find file:
'mm.MRG' (errno: 2) it
generally indicates that some of the base tables are not using
the MyISAM storage engine. Confirm that all
of these tables are MyISAM.
The maximum number of rows in a MERGE table
is 264 (~1.844E+19; the same as for
a MyISAM table), provided that the server
was built using the --with-big-tables option.
(All standard MySQL 6.0 standard binaries are
built with this option; for more information, see
Section 2.9.2, “Typical configure Options”.) It is not possible to
merge multiple MyISAM tables into a single
MERGE table that would have more than this
number of rows.
The MERGE storage engine does not support
INSERT DELAYED statements.
Using different underlying row formats in
MyISAM tables with a parent
MERGE table is currently known to fail. See
Bug#32364.
Starting with MySQL 6.0.4, you cannot change the union list of
a non-temporary MERGE table when LOCK
TABLES is in effect. The following does
not work:
CREATE TABLE m1 ... ENGINE=MRG_MYISAM ...;
LOCK TABLES t1 WRITE, t2 WRITE, m1 WRITE;
ALTER TABLE m1 ... UNION=(t1,t2) ...;
However, you can do this with a temporary
MERGE table.
Starting with MySQL 6.0.4, you cannot create a
MERGE table with CREATE ...
SELECT, neither as a temporary
MERGE table, nor as a non-temporary
MERGE table. For example:
CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...;
Gives error message: table is not BASE
TABLE.


User Comments
One thing to add: you can not create fulltext indexes on merge table.
If a MyISAM table is part of a MERGE table, you can not just copy the table files as you upgrade from MySQL 4.1 to 5.0. Instead, you HAVE TO dump the table and read it back in.
If you don't: you will get errors indicating that the tables are not defined identically.
Actually, you don't have to drop and repopulate your MyISAM tables; running an ALTER TABLE statement (for instance, using CHANGE COLUMN to transform the primary key into its current definition) will upgrade the MyISAM table to the current version and the MERGE table will continue to function.
You can see the MyISAM version in SHOW TABLE STATUS; notice that MyISAM tables created by MySQL 4.1 are version 9 and MyISAM tables created by MySQL 5.0 are version 10.
Add your own comment.