MERGE テーブルを別のストレージエンジンに変える為に、ALTER TABLEテーブルを利用すると、基礎となるテーブルへの位置付けが失われます。その代わりに、基礎となる MyISAM テーブルのレコードが変化したテーブルにコピーされ、そしてそれは指定されたストレージエンジンを利用します。

REPLACE は機能しません。

MERGE テーブルは領域確保をサポートしません。これは、MERGE テーブルも、MERGE テーブルの基礎となる MyISAM テーブルも領域確保ができないという事です。

開いているMERGE テーブルにマップされた全てのテーブルに対して、 WHERE 条項、 REPAIR TABLE、 TRUNCATE TABLE、 OPTIMIZE TABLE、また ANALYZE TABLEがない DROP TABLE、 ALTER TABLE、 DELETEを使う事はできません。それをすると MERGE テーブルは元のテーブルを参照する事があるので、好ましくない結果をもたらす可能性があります。このような事を防ぐのに一番簡単なのは、FLUSH TABLES ステートメントを事前に発行する事によって、全ての MERGE テーブルを閉じておくという方法です。

MERGE ストレージエンジンのテーブル位置づけはMySQLの上位レイヤーから隠れているので、MERGE テーブルによって使用されているDROP TABLE はWindowsでは機能しません。Windowsでは開いているファイルを削除する事はできないので、まず MERGE テーブルをフラッシュするか( FLUSH TABLESを使う)、テーブルをドロップする前にMERGE テーブルをドロップする必要があります。

MERGE テーブルは、そのテーブル全体に対して一意性制約を保持する事ができません。 INSERTを行う時、データは最初、または最後の MyISAM テーブルに入ります。( INSERT_METHOD オプションの値による。)MySQLは　MyISAM テーブルの中では一意の値はそのまま残る事を保障しますが、全てのテーブルのコレクションの中ではそうではありません。

MySQL 5.1.15以降のバージョンでは、アクセスされた時にMyISAM テーブルと MERGE テーブルの定義が確認されます。(例　 SELECT か INSERT ステートメントの一部として)。そのように確認する事によって、テーブル定義と親MERGE テーブル定義がカラムの順番、タイプ、サイズ、そして関連するインデックスなどに関して一致する事を保障します。テーブル間で違いがあれば、エラーが発生し、ステートメントは失敗します。

テーブルが開かれた時にこのようなチェックが行われるので、カラム変更、カラムの順番やエンジンの入れ替え等を含む定義の変更によってステートメントが失敗します。

MySQL 5.1.14 とそれ以前のバージョンにて

MERGE テーブル内と、その基礎となるテーブルのインデックスの順番は同一でなければいけません。もしMERGE テーブル内で使われるテーブルにUNIQUE インデックスを追加する為にALTER TABLEを使用し、またMERGE テーブルに一意ではないインデックスを追加するためにALTER TABLE を利用するなら、基礎となるテーブルの中に既に一意ではないインデックスがあれば、テーブルのインデックス順は異なります。(これは、 重複キーの速やかな検出を促進する為にALTER TABLE が UNIQUE インデックスを一意でないインデックスの前に置くからです。)その結果、そのようなインデックスを持つテーブルに対するクエリは予想外の結果をもたらします。

もし ERROR 1017 (HY000): Can't find file: 'mm.MRG' (errno: 2) と同じようなエラーメッセージが出たら、それは通常いくつかのベーステーブルがMyISAMストレージエンジンを使用していない事を表します。全てのテーブルがMyISAMである事を確認してください。

MyISAMにもあるように、MERGE テーブルにも2³² (~4.295E+09)行の制限があります。その為、この制限を越える複数のMyISAM テーブルをマージする事はできません。しかし、 MySQLを --with-big-tables オプションで作成すると、行の制限は (2³²)² (1.844E+19) 行に増加します。詳しくは項2.9.2. 「典型的な configure オプション」を参照してください。MySQL 5.0.4バージョンより、全ての標準バイナリはこのオプションで作成されます。