Является ли выполнение UPDATE в пакетном режиме для таблицы MySql быстрее, чем выполнение UPDATE по одному?

Question

Мне нужно выполнить запрос UPDATE ниже одного за другим ~ 500 раз в таблице MySql.Мне интересно, какой из этих двух будет иметь лучшую производительность?

1. UPDATE 'latency_table' SET 'is_active' = null WHERE rule_id = 1;

2. UPDATE 'latency_table' SET 'is_active' = null where rule_id in (1...500);

В # 1 я обращаюсь к таблице ~ 500 раз, но в # 2 я обращаюсь к таблице один раз, но все еще обращаюсь к строкам 500 раз.# 2 - более эффективное решение?

Answer 1

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

Answer 2

Каждый оператор, который вы отправляете в СУБД, должен быть проанализирован.Таким образом, вы отправляете СУБД свой SQL, и СУБД говорит: «А, обновление. Какая таблица? Таблица latency_. Какие строки? Идентификатор строки 1. Давайте подумаем, как быстро туда добраться ... У меня есть индекс? Да, такдля одной строки имеет смысл использовать его. Какие столбцы обновлять и с какими значениями? Столбец is_active и null. Хорошо. Давайте сделаем это. "

Для отдельных операторов вы делаете это примерно 500 раз.Для второго только один раз.

Затем вы запускаете оператор из где-то .Так что где-то нужно поговорить с СУБД: «Привет, у меня есть для вас заявление».- «Спасибо, я только что проверил. Выглядит хорошо».- Хорошо, тогда, пожалуйста, выполни это.- "Готово. Ваше обновление затронуло 500 строк."Это происходит для любого приложения, даже если это какой-то инструмент БД, такой как phpmyadmin.Это называется поездками туда и обратно.Этот разговор происходит для каждого отправляемого вами оператора.

Наконец, с одним оператором вы не даете СУБД никакой возможности для оптимизации.Допустим, вы обновляете 500 строк из 600. Это почти все строки.Если вы отправите одно обновление, СУБД будет искать эту запись.Если есть индекс, он быстро найдет его с помощью бинарного поиска (Посмотрите на строку № 300. Меньше? Посмотрите на строку 150. Больше? Посмотрите на строку 225 ...) В противном случае он должен прочитать всю таблицу.Для каждого утверждения.500 раз.Если вы отправите только один оператор на 500 строк, СУБД наверняка заметит, что будет непросто пробежаться по индексу для каждого идентификатора правила, и вместо этого просто прочитает таблицу последовательно один раз и будет готово.

ВозможноСУБД может даже выполнить ваш оператор распараллеленным.Четыре ядра процессора?Тогда каждое ядро ​​ЦП может заботиться о 150 записях одновременно.

Итак: множество причин сделать это в одном операторе обновления.И это то, что SQL в конце концов.Не беспокойтесь о том, как СУБД может решить проблему.Скажите ему, что делать (обновить эти 500 строк), а не как (один за другим).Он может даже решить выполнить 500 строк так, как если бы вы отправили 500 отдельных операторов, и все равно это было бы намного быстрее, потому что синтаксический анализ выполнялся только один раз и выполнялся намного реже.

Answer 3

В первом решении вы переходите от клиента к базе данных по сети и обратно - выдается оператор обновления, результат возвращается клиенту, выдается другой оператор и т. Д.Во втором решении вы отправляете все в базу данных один раз , позволяете ей делать свое дело и только после этого получаете ответ.Это определенно будет лучшим подходом.