Похоже первый ответ лучший.
Но не все понятно в описании
|
|---|
Для таблиц MERGE используется больше дескрипторов файлов. Если применяется таблица MERGE, преобразованная из более чем 10 таблиц, к которым получают доступ 10 пользователей, то используется 10*10 + 10 дескрипторов файлов (10 файлов данных для 10 пользователей и 10 общих индексных файлов).
Ключи считываются медленнее. При чтении ключа обработчику MERGE необходимо прочитать все базовые таблицы, чтобы выяснить, какая из них больше всего соответствует указанному ключу. Если после этого выполнить команду ``читать следующий'', то обработчик объединенной таблицы должен будет просмотреть буферы чтения, чтобы найти следующий ключ. Только по завершении использования одного буфера ключей обработчику понадобится прочитать следующий блок ключей. В связи с этим ключи MERGE дают большое замедление при поиске eq_ref, однако не такое значительное при поиске ref.
|
Зачем файлы каждой таблицы входящию в MERGE открывать для каждого пользователя отдельно, вроде бы для прото таблиц mysql ведет себя поразумнее?
Зачем читать данные чтобы получить ключи, почему нельзя взять прямо ключи из кеша? (или это неверно переведено?)
В create таблицы MERGE надо указывать индексы. Не будут ли они создаваться/обновляться при работе с отдельными таблицами? (таблица специально разрезана, чтобы работа с одной часть не мешала остальным)
Структура таблиц
md5 binary(16) not null,id_page binary(8) not null,body mediumtext not null,f binary(1) not null,index(md5 (6)),index(id_page (4))
В запросе вместо многоточия 10-30 тысяч констант binary(8) Оптимизировать тут нечего (кроме длинны индекса id_page)