Массажист,
уже очень давно известно, что таблицы с индексами (и ключами), особенно содержащие много записей, обновляются крайне медленно. Для примера: обновление БД при ежемесячном расчете пенсий и дотаций всех московских пенсионеров, включая инвалидов и их доверенных лиц (это 10 млн и более записей в каждой основной таблице), на самом современном оборудовании SUN Microsystems занимало несколько суток. За это время обязательно случалось какое-нибудь ЧП, и всё надо было начинать сначала. Но это было только до тех пор, пока не была применена следующая технология:
1) Делается актуальная копия БД в текущем состоянии (резервные копии и так создавались автоматически) во временную БД. Это обязательно! Прием новых данных на некоторое время прекращается, о чем оповещаются все клиентские приложения сети.
2) Во временной БД у таблиц (не всех) удаляются ключи и индексы.
3) Делается обновление данных, а иногда и удаление с последующим инсертом. Без индексных таблиц это получается на порядок быстрее!!!
4) Проводится контроль ссылочной целостности новой БД.
5) Ключи и индексы восстанавливаются специальной программой (это делается быстро).
6) Производится контроль взаимодействия ПО с новой БД.
7) В случае положительного результата рабочая БД заменяется на новую, которая становится рабочей. Перед этим бывшая рабочая база архивируется.
Такая технология обеспечивала быстрое (за несколько часов) и надежное обновление большой БД. Это было 20 лет назад, использовались СУБД Open Ingres, потом Oracle. Уверен, что сейчас появились специальные ПО (возможно, содержащееся в самих СУБД), которые все это делают (полу)автоматически, т.е. Вам не придется создавать и отрабатывать ПО в течение нескольких лет, как это делали мы, а надо будет найти соответствующий продукт и овладеть им. Я лишь попытался объяснить порядок и смысл основных шагов.

Массажист,
я забыл объяснить главное: почему обновление и вставка в таблицы, лишенные индексов, происходит быстрее, чем в таблицы с индексами. (Ведь что такое "индекс"? - Индексы содержатся в точно таких же таблицах, как все остальные, только таблицы индексов создаете не Вы, а СУБД, когда Вы назначаете какое-то поле Вашей таблицы индексным.) Дело в том, что при каждой операции INSERT в таблицу с индексами происходит и перестройка всех индексных таблиц, связанных с этой таблицей, а также изменение значений индексов в таблицах, связанных с ней через индексы.
Если же таблица очищена от индексов, то все обновления и добавления включаются в нее последовательно, "внавал". Это происходит так же быстро, как вставка в конец текстового файла символа или слова.
Если после всех изменений БД программа делает индексирование таблиц, то это происходит только ОДИН РАЗ, а не КАЖДЫЙ РАЗ при добавлении каждой новой записи в индексированную таблицу. В этом заключается весь смысл отключения индексов перед массовым обновлением реляционных баз данных, в том числе перед массовым добавлением записей.

Зурбаган!
Это способ, не только проверенный на практике, но и рекомендованной в теории еще основателями реляционной модели данных и РСУБД. Так что, спорите Вы даже не со мной, а с Коддом и Дейтом. Удалять индексы и потом их восстанавливать не так уж сложно: это простые операции, для которых один раз пишутся хранимые процедуры БД. На время обновления БД блокируется на ввод/изменение данных (все равно периодически проводятся регламентные работы - ТО), т.е. SELECT юзерам доступен. Если же нет такой возможности, то рабочая база продолжает работать, а обновление делается ее резервной копии, затем производится репликация двух баз - резервной из рабочей. В любом случае обновление таблиц без индексов происходит на 2 порядка быстрее, чем с индексами, а значит, это лучше даже с учетом блокировки.

"Волшебной" репликации не существует, несмотря на все то, что вещали промоутеры Мелкомягкого на московских конференциях для банков - первого, кто в 90-х годах заявил на всех своих конференциях и в печати, что для MS SQL разработаны такие программы репликации структур и данных БД, а также мониторы транзакций (стоимостью для нас в то время десятки тысяч долларов, мне запомнилось число 56), которые позволяют содержать на каждом из тысяч серверов - простых ПК, разбросанных по всему миру, реплицируемые БД (т.е. крупные серверы, якобы, более не нужны, такие системы, якобы, равносильны применению машины Super Cray с ее локальной сетью!). Уже давно этот искусственно раздутый для России рынок (базар) попритих, но пароксизмы "монитора транзакций" по-прежнему возникают время от времени. Правда, цены стали почему-то гораздо ниже.
На самом деле, при более пристальном рассмотрении, репликации оказались разными. Оказалось, что они зависят от требований конкретной информационной системы (ИС), и фактически всегда можно не учитывать все случаи жизни. Программы для репликаций могут быть совсем не сложными, не сложнее самих функций удаленного доступа, которые применяются при осуществлении репликации и которые сегодня поддерживаются всеми средствами разработки, в частности, MS Visual Studio (от общих для всех тенденций времени Майкрософту тоже уйти не удалось).
Получается так, что механизм репликаций, прежде чем применять, надо разработать и отработать прикладным и системным программистам вместе. Главное хорошо продумать технологию сеанса репликации: что надо делать и в какой последовательности. Это непросто: надо создать очень грамотную постановку задачи, а это сейчас далеко не все могут (потому что плохо знают предметную область, да и некому им ее изложить), и поэтому сегодня репликация, по моим наблюдениям, применяется редко (систематически - только на Дальнем Западе несколькими фирмами, наверняка порожденными самим MS). Чаще создается еще одна копия БД, в ней производятся изменения, затем производится замена баз, как я и описал. А так как аппаратная часть всех необходимых обеспечений (те, кто хоть мельком знакомы с теорией IT, сразу поняли, какой список "обеспечений" я имею в виду) стала намного производительнее, чем была, то замена происходит быстро. Однако не все так просто, как хотелось бы, и нескоро будет просто.
PS
Особенно не скоро, пока существуют флудеры и тролли, который хлебом не корми, но дай поиздеваться над "пенсионерами". Если бы в 90-х, когда они еще только что появились на свет или в лучшем случае уже кушали свои козявки, не затормозили (насильственно, под влиянием наших собственных либеральных демократов, ну и не без западных долларей, конечно) развитие науки и промышленности России и отделившихся "стран", и вместе с этим не похерили бы естественную преемственность поколений , то сегодня не пришлось вам, многим и многим программерам - нашим прямым потомкам - задавать подобные детские вопросы и миллионы раз изобретать все тот же самый велосипед в каждой отдельно взятой коммерческой организации, прикрываясь локтями от всех других подобных же программеров.