Насколько оберточные вставки в транзакции помогают повысить производительность на Sql Server? - PullRequest
9 голосов
/ 06 февраля 2009

Хорошо, скажем, у меня есть 100 строк для вставки, и каждая строка имеет около 150 столбцов (я знаю, что это звучит как много столбцов, но мне нужно хранить эти данные в одной таблице). Вставки будут происходить случайным образом (т. Е. Всякий раз, когда группа пользователей решит загрузить файл, содержащий данные), примерно 20 раз в месяц. Однако база данных будет постоянно обрабатывать другие функции приложения крупного предприятия. Колонны - это varchars, ints, а также множество других типов.

Будет ли выигрыш в производительности оборачивания этих вставок в транзакцию (а не запускать их по одному) огромным, минимальным или где-то посередине?

Почему?

EDIT: Это для Sql Server 2005, но я был бы заинтересован в 2000/2008, если есть что-то другое, чтобы сказать. Кроме того, я должен отметить, что я понимаю, что транзакции предназначены главным образом для обеспечения согласованности данных, но я хочу сосредоточиться на эффектах производительности.

Ответы [ 5 ]

17 голосов
/ 06 февраля 2009

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

Транзакции предназначены для обеспечения согласованности ваших данных. Это должно быть первым, о чем вы думаете при использовании транзакций. Например, если у вас есть дебет (снятие) с вашего текущего счета, вы хотите убедиться, что кредит (депозит) также выполнен. Если какой-либо из них не удастся, всю «транзакцию» следует откатить. Поэтому оба действия ДОЛЖНЫ быть включены в транзакцию.

При выполнении пакетной вставки разбивайте их на 3000 или 5000 записей и просматривайте набор. 3000-5000 был для меня прекрасным диапазоном чисел для вставок; не идите выше этого, если вы не проверили, что сервер может справиться с этим. Кроме того, я добавлю GO в пакет примерно каждые 3000 или 5000 записей для вставок. Обновления и удаления я поставлю GO около 1000, потому что они требуют больше ресурсов для фиксации.

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

9 голосов
/ 25 апреля 2012

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

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

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

Транзакции окончательно связаны с производительностью, независимо от их основного намерения.

2 голосов
/ 06 февраля 2009

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

При этом беспокоиться о производительности так или иначе, когда вы говорите только о вставке 100 строк данных примерно 20 раз в месяц (то есть 2000 записей в месяц), глупо. Преждевременная оптимизация - пустая трата времени; если вы неоднократно проверяли влияние этих вставок на производительность (как маленькое, так и нечастое) и не находили их серьезной проблемой, не беспокойтесь о производительности. Это незначительно по сравнению с другими вещами, которые вы упомянули в качестве нагрузки на сервер.

2 голосов
/ 06 февраля 2009

Транзакции не для производительности, а для целостности данных. В зависимости от реализации не будет никакого выигрыша или потери производительности только для 100 строк (они просто будут регистрироваться дополнительно, поэтому их можно будет откатить).

Что нужно учесть в вопросах производительности:

  • TA будут взаимодействовать с другими запросами
    • при написании TA блокируются кортежи / страницы / файлы
  • коммиты могут быть (в зависимости от протокола блокировки) обновлением временной метки
  • может быть записано больше журналов для ТА (можно откатить ТА, но БД уже может вести экстенсивный журнал, последовательное ведение журнала дешево)
  • степень изоляции (я знаю, что можно переключать этот уровень в некоторых БД - и что почти никто не использует уровень 3)

В целом: используйте ТА для обеспечения целостности.

2 голосов
/ 06 февраля 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...