Асинхронное закрытие таблицы?

voituk

прозревший
Асинхронное закрытие таблицы?

Производится анализ данных по такому алгоритму:
1. Из таблицы А (ОЧЕНЬ большой) с помощью "INSERT INTO ... SELECT" в таблицу B загружаются данные (порядка 200 тыс записей, всего порядка 40 млн записей)
2. Дальше из таблицы B формируется отчет и складывается в таблицу C (тоже с помощью "INSERT INTO ... SELECT")

Все это выполняется в shell-скрипте последовательными вызовами консольного MySQL:
п.1. mysql -u... -p... -e"INSERT INTO B ... SELECT ... FROM A" database
п.2. mysql -u... -p... -e"INSERT INTO C ... SELECT ... FROM B" database

В результате время от времени имеем ситуацию, при которой выполнениt п.1. уже завершилось, но при этом таблица "B" ещё в статусе нето "Closing table" нето "Repair with keycache" или что-то вроде этого (словить удалось только раз, но не придал значения и не запомнил точно). При попытке выполнить запрос к этой таблице - он успешно выполняется но возвращает пустой resultset.
Но при этом начинается выполнение п.2., который обрабатывает пустой resultset - в результате в таблицу C данные не поступают.

Если после п.1. дождаться закрытия таблицы "B" то п.2. выполняется отлично.

Попробовал поставить между п1. и п2. sleep 600, но IMHO это не выход.
Также пробовал делать все запросы в пределах одного подключения - та же "петрушка".

Все таблицы MyISAM
MySQL 4.1.15

show variables like '%concurrent%'; # Подозреваю что он тут при делах :)
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| concurrent_insert | ON |
+-------------------+-------+
1 row in set (0.01 sec)

Как избавиться от описанного асинхронного закрытия таблицы?
 

Alexandre

PHPПенсионер
а что мешает сделать текстовый файл из двух запросов
INSERT INTO В SELECT ....
INSERT INTO С SELECT... FROM B

а далее выполнить его из консоли
mysql -u... -p... -gfilename
 

.des.

Поставил пиво кому надо ;-)
Попробуйте обновить mysql. У меня похожая проблема возникала на одной из версий.
 

voituk

прозревший
.des.
Спасибо, но такой вариант исключен.

Есть другие предложения?
 

Апельсин

Оранжевое создание
Есть такой прикол, что управление уже возвращается, хотя фактически запрос еще не завершился:
http://bugs.mysql.com/bug.php?id=29334

можно сделать FLUSH TABLES перед вторым запросом, но учтите, что при этом будут сбрасываться на диск _все_ таблицы. На нагруженом сервере с большим кол-вом таблиц это будет ужасно.
 

voituk

прозревший
Апельсин
Спасибо за ссылку.

Буду пробовать выполнить FLUSH TABLES.

-~{}~ 02.10.07 11:15:

На текущем обьеме данных flush tables выполняется порядка 20 минут, но ошибка больше не возникает.
 
Сверху