Производительность обновления SQL (Server)

Question

Мои ограниченные знания SQL побудили этот пост!

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

Основы для использования в столице: 6 столов. 3 из которых никогда не будут содержать более 5000 записей, 3 из которых растут бесконечно (в настоящее время около 1-2 миллионов записей, правильно проиндексированы и т. Д.). Есть ли преимущество в скорости для объединения всех таблиц и выполнения одного массового заявления об обновлении, а также его сохранение в виде 6 отдельных обновлений?

Im ищет наиболее эффективный способ сделать это, даже если он бреет вторую.

Спасибо.

EDIT:

Приношу свои извинения всем. Я обновляю только одну таблицу, но проверяю данные из всех 6, чтобы обновить одну таблицу. (т. е. проверка, чтобы увидеть, является ли table2.somevalue пустым, а затем помечать запись в таблице1 как «ошибка»)

Answer 1

Если их можно комбинировать, то да, вы должны их комбинировать.

Если вы обновляете несколько столбцов из одной таблицы, а затем объединить их, как:

UPDATE mytable 
SET foo = bar, fizz = buzz, whiz = bang 
WHERE zing > 2081 

вместо

UPDATE mytable SET foo = bar WHERE zing > 2081 
UPDATE mytable SET fizz = buzz WHERE zing > 2081 
UPDATE mytable SET whiz = bang WHERE zing > 2081 

То есть почти 3x, как эффективно, потому что он только должен пройти через таблицу один раз.

Обновления полей в разных таблицах необходимо выполнять отдельно (как упоминалось в Cade Roux, его возможно даже , чтобы сделать их в то же самое время).

Даже если вы используете сложное соединение, за один раз может быть обновлена ​​только одна таблица.Что-то вроде:

UPDATE AccountHistory 
SET LastPurchaseDate = i.PurchaseDate 
FROM Account a 
INNER JOIN AccountHistory h ON a.AccountID = h.AccountID 
INNER JOIN Invoices i ON i.AccountID = a.AccountID 
WHERE i.PurchaseDate > '2009-11-30' 

Здесь меняется только учетная запись, хотя доступ к исходным данным осуществляется через соединение.

Answer 2

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

С почти всеми современными пакетами баз данных существует множество других доступных вам технологий которые увеличивают производительность без изменения базовой схемы таблицы. Вы можете добавлять индексы, настроенные к типам запросов, которые использует ваше приложение. Среди других методов вы можете добавить индексированные представления (материализованные представления в Oracle). Вы можете вертикально и/или горизонтально разделять таблицы. В SQL Serve вы можете «ПИН» небольшие таблицы, чтобы они все время находились в памяти.

Answer 3

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

Я думаю, что 6 обновлений (при необходимости в транзакции) более понятны, чем 1 большое обновление, поэтому это лучшее решение, и вы можете оптимизировать каждое обновление настолько быстро, насколько это возможно.

JRud комментарий хороший - вы всегда можете попробовать в оба конца и сравнить время.

Answer 4

Значительные улучшения производительности, как правило, могут быть достигнуты путем группирования запросов, , когда запросы поступают из [удаленного] клиента. В вашей ситуации несколько запросов поступают из хранимой процедуры и, следовательно, с готовностью являются локальными запросами, и преимущества их объединения не будут существенными, если вообще.

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

Однако, так как вы, кажется, ищите наиболее эффективный способ, вам нужно попробовать различные возможности (под представительным набором входов данных), чтобы увидеть эффект от конкретных изменений.В отсутствие более подробной информации о вашей конкретной ситуации трудно предложить более целенаправленную информацию.

Один маленькие и общий намек:
Упоминания «проиндексированы надлежащим образом» со ссылкой на «большую» таблицу, является напоминанием о том, что, когда дело доходит до обновления (и в более общем плане записи операции, как удаление и вставка), индексы может быть большей частью ответственности за активы, с точки зрения производительности.

Answer 5

Это не возможно (обновление нескольких таблиц одновременно в одном выражении UPDATE) в T-SQL.

От BOL:

table_name

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

и

view_name

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

Answer 6

Вы пытаетесь улучшить общую производительность хранимой процедуры или сократить время, которое ОБНОВЛЯЕТСЯ?

В случаях, когда меня больше беспокоит параллелизм (сокращение времени блокировки), чем общая производительность, я буду выбирать значения ключей в переменных или временных таблицах. Затем я использую переменные или временные таблицы в UPDATE. «Фокус» может значительно улучшить производительность UPDATE.

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