минимизировать время при обновлении таблицы с левой присоединиться к

Question

У меня есть 2 таблицы, как:

-table1: id_1, id_2, id_3, ref_id (id_1, id_2 is pk) 
-table2: ref_id, id_4 

Я хочу id_3 поле должно быть равно id_4 TABLE2 (в ref_id является первичным ключом) table1 имеет около 6 миллионов записей и таблица2 имеет около 2700 записей.

я написал SQL, как:

update table1 
set id_3 = b.id_3 
from table1 
left join table2 b on id_1= b.ref_id 

С помощью SQL Server запрос занимает так много времени, как около 16 часов и до сих пор нет ответа. Как уменьшить время запроса?

Answer 1

Обновление каждой строки в таблице из 6 миллионов строк, вероятно, будет медленным независимо.

Один из способов, чтобы получить эталоном для максимальной скорости обновления каждой строки будет только время запроса:

update table1 
set id_3 = 100 

Кроме того, вы должны обновлять строки в table1, которые не имеют соответствующих строк в table2 ? В этом случае переключение левого внешнего соединения на внутреннее соединение значительно повысило бы производительность.

Answer 2

Похоже, что это действительно абсурдно долго, но недостатком индексов может быть причина этого. Без индексов база данных в основном должна проходить через 2700 записей для каждой отдельной записи в вашей таблице записей 6M.

Итак, начните с добавления индекса (при условии, что первичный ключ не является индексом) на ref_id, а также добавьте индекс на id_1.

Чтобы упростить мониторинг (с точки зрения прогресса), просто проведите 2700 записей в таблице 2 и выполните обновление на запись (или на 10, 100 и т. Д.), Чтобы вы могли обновлять по частям и видеть как далеко оно доходит.

Кроме того, чтобы убедиться, что вы ничего бесполезного не делать, я бы рекомендовал добавление and table1.id_3 <> table2.id_3

Answer 3

Для того, чтобы ответить на этот вопрос, нам действительно нужно знать, что кластерные индексы на двух таблицах. Я могу сделать предложение для кластеризованных индексов быстро сделать этот конкретный запрос, однако при выборе кластеризованных индексов действительно следует учитывать другие факторы.

Так с этим в виду, см, если эти показатели помогают:

table1: УНИКАЛЬНАЯ кластерный индекс (ID_1, ID_2) table2: УНИКАЛЬНАЯ кластерный индекс (ref_id)

В основном делают ваши PKs кластерный если их еще нет.

Другое важное обстоятельство заключается в том, видят ли таблицы другой трафик во время выполнения этого обновления. Если это так, то длительное время выполнения может быть связано с блокировкой. В этом случае вы должны рассмотреть пакетную обработку, то есть обновлять только небольшую порцию за раз, а не все в одном выражении.