Таблица tmp не растет при запуске ALTER для добавления нового столбца

У меня есть таблица размером около 25 ГБ, в которую я должен добавить столбец.

Я запускаю скрипт, и когда я его выполняю, я вижу временную таблицу в каталоге данных, но она остается на уровне около 480 КБ. Я вижу в списке процессов, что ALTER работает и проблем нет.

Если я убью скрипт после долгого периода активности, то в списке процессов запрос останется в состоянии «убито», и файл tmp начнет расти, пока запрос не будет БУКВАЛЬНО убит (т.е. не перейдет из состояния «убито» в списке процессов в исчезновение полностью исключен из списка процессов).

Когда я запускаю следующее (перед тем, как убить запрос):

select * from global_temporary_tables\G

он также не показывает добавленных строк.

Есть ли что-нибудь еще, что я могу сделать?


mysql alter percona datadirectory
person user3299633    schedule 13.07.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Во-первых, то, что может показать ваш выходной отчет «ps», не имеет ничего общего. Не полагайтесь на то, что говорит «ps»: это включает устаревшие данные.

Если процесс был убит (SIGKILL, а не SIGTERM), я гарантирую вам, что он больше никуда не доставляет вывод. Если он был SIGTERMed, это зависит от того, какие обработчики сигналов вы прикрепили. Рискну предположить, что вы не зарегистрировали никаких обработчиков сигналов.

Большинство производственных СУБД настраивают хранилище фрагментами. Получается X пространства, которое может содержать «свободное» пространство, позволяющее добавлять строки и/или столбцы (я НЕ говорю, что эти два механизма идентичны). То, что что-то не росло так, как вы могли бы это воспринять, не означает, что изменений не было. Почему бы не проверить словарь данных, запросив текущую структуру таблицы.

Вы СОВЕРШИЛИ свои изменения? В некоторых СУБД операции DDL рассматриваются как события фиксации/отката (yecch).

person Bruce David Wilner    schedule 14.07.2016