Медленный UPDATE на SQL Server, даже если обновления не обновляются

Question

Не обнаружено проблем с блокировкой таблицы.

У меня есть инструкция по обновлению, аналогичная этому.

UPDATE table1 
SET table1.col1 = table2.col2 
FROM table1,table2 
WHERE table1.id = table2.id 

Это берет навсегда, даже в случае Whee нет записей для обновления

работает запрос

SELECT * 
FROM table1,table2 
WHERE table1.id = table2.id 

мгновенно.

РЕШЕНИЕ НАЙДЕНО: для этого я включил «Включить фактический план выполнения», как было предложено, и рекомендовал 3 индекса, которые у меня не были, и теперь выполняет всю хранимую процедуру, которая составляет 190 операторов SQL, работающих на таблицах с 16 миллионами строк менее чем за 1 минуту. Грейсиас тому, кто это предложил.

Answer 1

Вы можете использовать собственное присоединиться:

Update t 
SET t.Col1 = t2.col2 
FROM table1 t INNER JOIN 
table2 t2 ON t.PK = t2.FK 

После этого проверьте все дополнительные процессы, запущенные на этом сервере.

Используйте SQL Profiler, чтобы увидеть, что происходит за кулисами. Посмотрите, есть ли какие-либо необычные процессы/задания, которые могут повлиять на обновление. не

Это берет навсегда, даже в случае Whee нет записей в обновления

Это также, как упомянуто обновление всего до тех пор, как Соединить существует, не существует, когда условие остановки его от не обновление. Каждая отдельная строка в таблице обновляется, значение, которое col1 имеет из таблицы t, перезаписывается значением col2 из t2.

также раздел комментариев:

@Bart - и вы понимаете, что вы обновляете 16 миллионов кортежей, то право? В вашем запросе ничего не говорится о том, что значение col1 равно , переписанное col2, даже если col1 и col2 содержат одинаковое значение. Вы должны сделать что-то к эффекту WHERE col2 <> col1, так что вы только обновления значений, которые отличаются

Answer 2

На самом деле, вы обновляете каждую строку каждый раз. Вам нужно добавить следующую строку в ваш ИНЕКЕ:

AND table1.col1 <> table2.col2 

Вы можете добавить ISNULL упаковщиков в каждую сторону, если это обнуляемое поле.

Что происходит быстрее: чтение книги или запись над каждым словом в книге того же самого точного слова? Просто потому, что вы пишете одно и то же значение по сравнению с исходным значением, это не меняет того факта, что вы пишете значения.

Теперь, если у вас есть предложение where, которое отфильтровывало записи, имеющие соответствующие значения, и у вас все еще была очень низкая производительность, тогда у потенциального виновника было бы слишком много индексов. Я предполагаю, что это не ваша проблема здесь ...

Answer 3

Update t 
SET t.Col1 = t2.col2 
FROM table1 t 
INNER JOIN table2 t2 ON t.PK = t2.FK 
where t.Col1 <> t2.col2 

Это то, что вы должны бежать. SQL Server не заботится о том, чтобы значения соответствовали ему, так или иначе, обновляя их.

И я с @JonH, эти соединения implict являются antipattern sql и были заменены чем-то лучшим 20 лет назад, нет никакого оправдания, чтобы все еще писать запросы таким образом. Вы получаете случайные кросс-соединения, и их сложнее поддерживать. Additonaly, в SQL Server подразумеваемые левые и правые соединения были устаревшими, и они никогда не работали корректно. Поэтому, если вам нужно перейти на левое соединение в обслуживании, вам придется изменить весь запрос, потому что объединение implict и явных соединений может привести к неправильным ответам.