ОБНОВЛЕНИЕ против производительности INSERT

Question

Верно ли предположить, что запрос UPDATE требует больше ресурсов, чем запрос INSERT?

Answer 1

Я не гуру базы данных, но вот мои два цента:

Лично я не думаю, что у вас есть много дел в этом отношении, даже если INSERT будет быстрее (все будет доказано), вы можете конвертировать обновление во вставку ?! Честно говоря, я не думаю, что вы можете сделать это все время.

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

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

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

Во всяком случае, нашел это как ссылку:

Лучшие 84 совета по производительности MySQL

Answer 2

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

Выполнение крупномасштабных обновлений по сравнению с созданием множества новых таблиц и индексов доказало, что процесс выставления счетов моей компанией сократился с 26 часов до 1 часа!

Я пробовал это на 2 миллионах записей для 100 000 клиентов. Сначала я создал таблицу счетов-фактур, а затем для каждого сводного звонка клиента я обновил таблицу счетов-фактур, указав продолжительность, цену, скидку ... всего 10 полей.

Во втором варианте я создал 4 фазы. Каждая фаза читает предыдущую (ые) таблицу (ы), создает индекс (после завершения вставки таблицы) и использует: «insert into from select ...». Я создал следующую таблицу для следующей фазы.

Резюме Хотя вторая альтернатива требует гораздо больше дискового пространства (все представления и временные таблицы удалены в конце), у этой опции есть 3 основных преимущества: 1. Это было в 4 раза быстрее, чем вариант 1. 2. В случае возникновения проблемы в середине процесса, я мог начать процесс с того места, где он вышел из строя, так как все таблицы для начала фазы были готовы, и процесс мог быть перезапущен с этого момента. Если процесс не реализует первый вариант, вам нужно будет начать весь процесс заново. 3. Это сделало разработку и контроль качества намного быстрее, так как они могли работать параллельно .

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

Это зависит. Простое ОБНОВЛЕНИЕ, которое использует первичный ключ в предложении WHERE и обновляет только одно неиндексированное поле, вероятно, будет дешевле, чем INSERT в той же таблице. Но даже это зависит от задействованного движка базы данных. ОБНОВЛЕНИЕ, которое включает изменение многих индексированных полей, однако, может быть более дорогостоящим, чем ВСТАВКА в этой таблице, потому что потребуется больше модификаций ключа индекса. ОБНОВЛЕНИЕ с плохо сконструированным предложением WHERE, требующее сканирования таблицы миллионов записей, безусловно, будет дороже, чем INSERT для этой таблицы.

Эти утверждения могут принимать различные формы, но если вы ограничите обсуждение их «базовыми» формами, которые включают в себя одну запись, то большая часть затрат будет обычно посвящена изменению индексов. Каждое индексированное поле, которое изменяется во время ОБНОВЛЕНИЯ, обычно включает две основные операции (удаление старого ключа и добавление нового ключа), тогда как для INSERT требуется одно (добавление нового ключа). Конечно, кластеризованный индекс затем добавил бы некоторую другую динамику, такую ​​как проблемы с блокировкой, изоляция транзакций и т. Д. Таким образом, в конечном итоге сравнение этих операторов в общем смысле не представляется возможным и, вероятно, потребовало бы сравнительного анализа конкретных операторов, если оно действительно имело значение.

Как правило, однако, имеет смысл просто использовать правильное утверждение и не беспокоиться о нем, поскольку обычно это не вариант выбора между ОБНОВЛЕНИЕМ и ВСТАВКОЙ.

Answer 7

Нельзя сравнивать ВСТАВКУ и ОБНОВЛЕНИЕ в целом.Приведите нам пример (с определением схемы), и мы объясним, какой из них стоит дороже и почему.Кроме того, вы можете конкурировать с конкретной ВСТАВКОЙ и ОБНОВЛЕНИЕМ, проверив их план и время выполнения.

Тем не менее, некоторые правила:

• , если вы обновляете только одно поле, котороене индексируется, и вы обновляете только одну запись, и вы используете rowid / primary key, чтобы найти эту запись, тогда это ОБНОВЛЕНИЕ будет стоить меньше, чем
• ВСТАВКА, что также повлияет только на одну строку, хотя в этой строке будет многоиндексированные поля не ограничены нулем;и все эти индексы должны быть сохранены (например, добавить новый лист)