Запрос к нескольким таблицам одной структуры

mihail_13
Дата: 03.01.2013 23:10:32
Запрос select p1 from t where p2 in (...)
Как быстрее получить результат?
Если к каждой таблице обращаюсь отдельно mysql где-то спит (процессор не загружен, свободная память есть, диски не загружены).
Если объединяю в один запрос он выполняется через временную таблицу и все тормозит.
Akina
Дата: 03.01.2013 23:15:08
merge storage engine
miksoft
Дата: 04.01.2013 00:05:57
А что в скобках после IN ? Набор констант или SELECT ?
Если SELECT, то переписывайте IN на JOIN.
Если набор констант, то показывайте как объединяете в один запрос.
javajdbc
Дата: 04.01.2013 00:12:32
mihail_13
Запрос select p1 from t where p2 in (...)
Как быстрее получить результат?
Если к каждой таблице обращаюсь отдельно mysql где-то спит (процессор не загружен, свободная память есть, диски не загружены).
Если объединяю в один запрос он выполняется через временную таблицу и все тормозит.


вы говорите загадками.

Будет намного интереснее, если будут
-- структура таблиц (DESC)
-- имеюшиеся индексы (DESC)
-- рамеры таблиц (count)
-- EXPLAIN каждого запроса который вы хотите обсудить
-- точные скорости (ms)
mihail_13
Дата: 04.01.2013 00:41:32
Похоже первый ответ лучший.
Но не все понятно в описании
Для таблиц 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)
mihail_13
Дата: 04.01.2013 12:48:54
А на практике оказалось еще хуже. При использовании MERGE регулярно уничтожаются файлы первой вписанной в него таблицы.
miksoft
Дата: 04.01.2013 13:07:00
mihail_13
А на практике оказалось еще хуже. При использовании MERGE регулярно уничтожаются файлы первой вписанной в него таблицы.
Случаем, вы не пытаетесь назвать MERGE-таблицу одинаково с первой включаемой таблицей?
mihail_13
Дата: 04.01.2013 14:16:39
Нет названия разные и проблема проявляется после первого запроса через MERGE.
Такое впечатление что у mysql где-то мозги заклинивает. Приходится все удалять и заново делать.
Возможно в 5.0.41 (или вообще) нельзя одновременно работать с таблицами и через MERGE и напрямую или я какую-то тонкость упустил.
bochkov
Дата: 04.01.2013 16:01:51
Я в версии 4.0... использовал merge таблицу, все отлично работало,
неужели технология с развитием версий деградировала.
А не могли бы вы показать ваши таблицы через SHOW CREATE?
mihail_13
Дата: 04.01.2013 17:22:10
Разобрался, нельзя восстанавливать из архива таблицы входящие в MERGE, не сделав FLUSH TABLES.