Для механизма хранения InnoDB для индекса кластера будет быстрее указывать индекс кластера (т. Е. PRIMARY KEY) в таблице до вставки данных.
Это происходит потому, чтоесли кластерный индекс (PRIMARY KEY) не определен в таблице, то InnoDB будет использовать скрытый 6-байтовый счетчик с автоинкрементным увеличением для индекса кластера.Если PRIMARY KEY указывается позже, необходимо перестроить всю таблицу.
Для вторичных индексов (т. Е. Некластерных индексов) с InnoDB обычно быстрее вставлять данные без определения вторичных индексови затем создайте вторичные индексы после загрузки данных.
FOLLOWUP
Что касается скорости загрузки в таблицу (в частности, в таблицу, которая усекается / очищается)и затем перезагружается), удаление и повторное создание индексов - это хорошо известный метод ускорения обработки не только с MySQL, но и с другими СУБД, такими как Oracle.)
Нет гарантии, чтообработка будет быстрее;как и в случае с базой данных большинства вещей, нам нужны тесты, чтобы определить, какой из них быстрее.
Для таблицы, содержащей миллионы строк, и мы добавляем пару десятков сотен строк, тогда удаление и перестройка индексов, вероятно, будутнамного медленнее, из-за всей дополнительной работы по переиндексации всех существующих строк.Поддерживать индекс было бы быстрее, пока вставлялись строки.
С точки зрения ускорения загрузки методика «удаления и повторного создания индексов» не даст нам существенных улучшений.мы получаем от других изменений.Например, это будет не то улучшение, которое мы увидим, если использовать LOAD DATA вместо INSERT операторов или многострочных INSERT операторов по сравнению с серией одноэлементных INSERT операторов.