MySQL почти во всех случаях перестраивает таблицу во время ALTER **. Это связано с тем, что движки на основе строк (т. Е. Все они) ДОЛЖНЫ сделать это, чтобы сохранить данные в правильном формате для запросов. Это также потому, что вы можете внести множество других изменений, которые также потребуют перестройки таблицы (например, изменение индексов, первичных ключей и т. Д.)
Я не знаю, какой движок вы используете, но я приму MyISAM. MyISAM копирует файл данных, внося любые необходимые изменения формата - это относительно быстро и вряд ли займет гораздо больше времени, чем аппаратное обеспечение ввода-вывода может вставить старый файл данных и новый на диск.
Восстановление индексов действительно убийственно. В зависимости от того, как вы его настроили, MySQL будет либо: для каждого индекса помещать индексированные столбцы в буфер файловой сортировки (который может быть в памяти, но обычно находится на диске), сортировать его с помощью функции filesort () (которая выполняет быструю сортировку). путем рекурсивного копирования данных между двумя файлами (если они слишком велики для памяти), а затем построения полного индекса на основе отсортированных данных.
Если он не может выполнить трюк с сортировкой файлов, он будет вести себя так, как будто вы сделали INSERT для каждой строки, и по очереди заполнит блоки индекса данными каждой строки. Это мучительно медленно и приводит к далеко не оптимальным показателям.
Вы можете узнать, что он делает, используя SHOW PROCESSLIST во время процесса. «Восстановление с помощью сортировки файлов» - это хорошо, «Восстановление с помощью кеширования» - это плохо.
Все это будет использовать НАИБОЛЕЕ одно ядро, но иногда будет также связано с IO (особенно при копировании файла данных).
** Существуют некоторые исключения, такие как удаление вторичных индексов в таблицах плагинов innodb.