|
Задавайте вопросы, мы ответим
Вы не зашли.
Есть табличка на 33кк записей, файл данных весит 5.6Гб, индексный - 3.8Гб. При выполнении запроса перегона данных в пустую таблицу INSERT INTO SELECT FROM, временный файл уже вырас до 25Гб и не перестаёт расти при скорости 10мб в секунду...
У меня паника, место в фс скоро закончится)) До скольки он может вырасти и почему такое происходит? В новой таблице добавлено всего одно поле даты, остальная структура та же, при этом индексов меньше. Я понимаю, что пока я получу ответ здесь, мускль уже закончит задачу, но вот откуда такой размер, поясните плз 
Неактивен
А было-то всего 46Гб места, и не хватило 
101230 16:07:23 [ERROR] /usr/local/libexec/mysqld: Incorrect key file for table '/home/mysqltmp/#sql966f_2_0.MYI'; try to repair it
При чём в момент копирования данных во временную таблицу, временного файла индекса *.MYI даже небыло создано.
Но при попытках провернуть сей трюк при размещении временных данных в меньших по размеру ФС, данное сообщение ошибки выдавалось через несколько секунд после начала выполнения запроса. А большего размера ФС на сервере нету
Памажите кто чем сможет
Неактивен
Так не бывает Можете структуры таблиц показать?
И SHOW TABLE STATUS на первую — может, она у Вас ужатая, например.
Неактивен
Структуры щас не покажу, коммерческая тайна))) В общем, задачу решил. Судя по всему, таблица с данными была не оптимизирована, все индексы были по нолям. По идее, это не должно влиять, но тем не менее, взял данные таблицы из бекапа и всё удачно слилось.
При этом хочу заметить, что в случае с проблемой в SHOW PROCESSLIST всегда показывало "Copying to tmp table", а в случае с оптимизированной таблицей всегда было "Sending data".
Могла ли быть проблема из-за того, что данные таблицы не были оптимизированы?
Неактивен
Битые таблички в любом случае могут приносить вред окружающей среде
Неактивен
