7.2.1 Проблемы при работе с таблицами MERGE

При работе с таблицами MERGE могут возникать следующие проблемы:

• Для таблицы MERGE не могут поддерживаться ограничения UNIQUE по всей таблице. При выполнении команды INSERT данные помещаются в первую или последнюю таблицу (в соответствии с INSERT_METHOD=xxx) и для этой таблицы MyISAM обеспечивается однозначность данных, но ей ничего не известно о первой таблице MyISAM.
• Команда DELETE FROM merge_table без оператора WHERE очищает только распределение для таблицы, ничего не удаляя из преобразованных таблиц.
• Использование команды RENAME TABLE над активной таблицей MERGE может привести к повреждению таблицы. Эта ошибка будет исправлена в MySQL 4.0.x.
• При создании таблицы типа MERGE не проверяется совместимость типов базовых таблиц. Создав таблицу MERGE на основе несовместимых типов, вы можете столкнуться с непредсказуемыми проблемами.
• Если для первого добавления индекса UNIQUE в таблицу, преобразованную в MERGE, используется команда ALTER TABLE, а затем командой ALTER TABLE в таблицу MERGE добавляется нормальный индекс, порядок ключей для таблиц будет разным, если в таблице был старый не однозначный ключ. Это происходит потому, что команда ALTER TABLE помещает ключи UNIQUE перед нормальными ключами, чтобы как можно раньше обнаружить дублирующиеся ключи.
• Оптимизатор диапазона пока не может эффективно использовать таблицу MERGE, в связи с чем иногда возникают неоптимальные соединения. Это будет исправлено в MySQL 4.0.x.

Команда DROP TABLE над таблицей, преобразованной в таблицу MERGE, не будет работать под Windows, так как обработчик MERGE скрывает распределение таблиц от верхнего уровня MySQL. Поскольку в Windows не разрешается удалять открытые файлы, сначала необходимо сбросить на диск все таблицы MERGE (при помощи команды FLUSH TABLES) или удалить таблицу MERGE перед тем, как удалить таблицу. Эту ошибку мы планируем исправить одновременно с введением VIEWs.

User Comments

If your key values are not unique across all
tables - a row in each table with a primary key
value of 100, for instance - then an exact key
lookup - "... where x = 100" - gives you only the
matching row from the first table from the UNION.
A range or pattern match query - " .... where x
like 100" - however, gives you both rows. If
that's not considered a "problem", then it's
certainly an
interesting feature. It's one thing to say that
unique keys
can't be enforced across the multiple tables. It's
quite
different to simply ignore non-unique key values - and
to only ignore them sometimes, at that.

When using select max(<varname>) from a merge
table with only one matching entry, it returns a NULL
result, however, using select min(<varname>)
returns the correct result. The workaround is to use
a select max(<varname>) on the underlying tables
comprising the merge table.

Add your own comment.