Может ли убитый оператор ALTER TABLE оставить индекс частично построенным?

Question

Мы запустили ALTER TABLE, который отбросил один индекс и добавил другой.Хотя мы ожидали, что таблица будет заблокирована только для записи, чтение началось в очереди, поэтому мы убили процесс ALTER.Но когда KILL закончил, старый индекс ушел, и новый индекс был на его месте, с гораздо меньшей кардинальностью, чем ожидалось.

Поиск по таблице теперь кажется быстрее, поэтому кажетсяАЛЬТЕР прошел хорошо, но мы не уверены.Возможно ли, что наш KILL покинул индекс в частично построенном этапе?

Answer 1

Если индекс существует, вы можете предположить, что он завершен.

Вы можете использовать SHOW CREATE TABLE или SHOW INDEXES, чтобы увидеть индексы в таблице.

Как отмечено вкомментарии, количество элементов, перечисленное SHOW INDEXES, является лишь приблизительным.

Один из тестов, которые вы можете попробовать, - это запустить SHOW INDEXES, затем запустить ANALYZE TABLE, затем снова запустить SHOW INDEXES и посмотреть, как изменяется оценочное значение количества элементов.

Answer 2

По вашему описанию (оба чтения / записи заблокированы) вы, скорее всего, используете более старую версию InnoDB или добавляете индекс к столбцу в наборе символов utf8.

Вот как это работает в вашей версии:

1. Пустая таблица создается с новым определением таблицы.
2. Строки копируются 1 за другой из старой таблицы в новую таблицу (также создаются новые индексы).
3. После завершения копирования старая таблица удаляется, новая таблица переименовывается.

(Если вы отмените действия между шагами 2 и 3, новая таблица будет просто благополучно удалена.)

Дляполное раскрытие - вот как это работает в плагине InnoDB (по умолчанию для MySQL 5.5, доступно из 5.1 +):

1. Таблица считывается, чтобы найти данные для индекса, и записывается во временный файл.
2. Временный файл отсортирован.
3. Индекс создается путем вставки данных по порядку.

(Этот метод более оптимизирован. Вызовы InnoDB "быстрые"создание индекса ".)