Должен ли я разбить большие запросы SQL (MS)

Question

Это относится к MS SQL Server 2005.

У меня есть пакет служб SSIS, который проверяет данные между двумя различными источниками данных.Если он находит различия, он создает и выполняет сценарий обновления SQL, чтобы решить проблему.Сценарий обновления SQL запускается в конце пакета после обнаружения всех различий.

Мне интересно, если это необходимо или хорошая идея для некоторых, как разбить сценарий обновления SQL на несколько транзакций и чтолучший способ сделать это.

Сценарий обновления выглядит примерно так, но длиннее (пример):

 Update MyPartTable SET MyPartGroup = (Select PartGroupID From MyPartGroupTable
 Where PartGroup = "Widgets"), PartAttr1 = 'ABC', PartAttr2 = 'DEF', PartAttr3 = '123' 
 WHERE PartNumber = 'ABC123';

Для каждой найденной ошибки / разницы в обновление добавляется дополнительный запрос на обновление.Сценарий.Я ожидаю только около 300 обновлений в день, но иногда их может быть 50 000.Должен ли я разбивать скрипт на транзакции, скажем, 500 запросов на обновление или что-то в этом роде?

Answer 1

Нет, я думаю, что заявление хорошо, как оно есть. Это не будет иметь большого значения в скорости вообще. Билли делает правильную точку, если вы заботитесь о читабельности запроса (вы должны это делать, если этот запрос будет просмотрен или использован в будущем.)

Answer 2

не оптимизируйте ничего, пока не узнаете, что есть проблема. если он работает быстро, отпустите. если он работает медленно, внесите некоторые изменения.

Answer 3

Все записи, затронутые запросом, будут либо заблокированы, либо скопированы в tempdb, если транзакция работает на SNAPSHOT уровне изоляции.

Если количество записей достаточно велико, блокировки могут быть увеличены.

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

Если уровень изоляции транзакции равен SNAPSHOT, тогда tempdb должен содержать достаточно места для размещения старых версий записей, иначе запрос не будет выполнен.

Если что-то из этого представляет для вас проблему, то вам следует разбить обновление на несколько частей.

Answer 4

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

Преимущество выполнения нескольких транзакций заключается в том, что вы не будете постоянно накапливать блокировки. Если вы выполните все эти обновления сразу, SQL Server в конечном итоге исчерпает мелкозернистые ресурсы блокировки (строка / ключ) и обновится до блокировки таблицы. Когда это будет сделано, никто больше не сможет читать из этих таблиц, пока транзакция не завершится (если они не используют грязное чтение или не находятся в режиме моментального снимка).

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

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

Answer 5

Это не должно быть проблемой, чтобы разделить вещи.Однако, если вы хотите A. поддерживать согласованность между элементами и / или B. работать немного лучше, вы можете использовать одну транзакцию для объекта while.

BEGIN TRANSACTION;
//Write 500 things
//Write 500 things
//Write 500 things
COMMIT TRANSACTION;

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