UPDATE vs INSERT performance

Question

Czy mam rację, zakładając, że zapytanie UPDATE zabiera więcej zasobów niż zapytanie o numer INSERT?

Dzięki,

Answer 1

Nie jestem guru w bazie, ale tutaj moje dwa centy:

Osobiście nie sądzę, masz wiele do zrobienia w tym zakresie, nawet jeśli byłoby szybciej INSERT (wszystko być sprawdzonym), czy możesz zamienić aktualizację we wkładce ?! szczerze mówiąc, nie sądzę, że możesz to zrobić przez cały czas.

podczas INSERT zwykle nie musisz używać WHERE, aby określić, który wiersz ma zostać zaktualizowany, ale w zależności od indeksów na tej tabeli operacja może mieć pewne koszty.

podczas aktualizacji, jeśli nie zmienisz żadnej kolumny zawartej w indeksach, które można szybko wykonać, jeśli klauzula where jest łatwa i wystarczająco szybka.

nic nie jest napisane na kamieniach i naprawdę wyobrażam sobie, że to zależy od konfiguracji bazy danych, indeksów i tak dalej.

tak, że ten jeden jako odniesienie:

Top 84 MySQL Performance Tips

Answer 2

to zależy. Prosta UPDATE, która używa klucza podstawowego w klauzuli WHERE i aktualizuje tylko jedno nieindeksowane pole, prawdopodobnie byłaby mniej kosztowna niż INSERT w tej samej tabeli. Ale nawet to zależy od silnika bazy danych. AKTUALIZACJA, która wymagała modyfikacji wielu indeksowanych pól, może być jednak droższa niż INSERT w tej tabeli, ponieważ wymagane będą więcej modyfikacji klucza indeksu. Aktualizacja z źle skonstruowaną klauzulą ​​WHERE wymagającą skanowania tabeli milionów rekordów z pewnością byłaby droższa niż INSERT na tym stole.

Te oświadczenia mogą przybierać różne formy, ale jeśli ograniczysz dyskusję do ich "podstawowych" formularzy, które dotyczą pojedynczego rekordu, wówczas większa część kosztu będzie zwykle przeznaczona na modyfikację indeksów. Każde indeksowane pole, które zostało zmodyfikowane podczas aktualizacji, zwykle wymaga dwóch podstawowych operacji (usunięcie starego klucza i dodanie nowego klucza), natomiast INSERT wymaga jednego (dodaj nowy klucz). Oczywiście, indeks klastrowy dodałby wtedy trochę innej dynamiki, jak problemy z blokowaniem, izolację transakcji itp. Ostatecznie porównanie tych stwierdzeń w sensie ogólnym nie jest naprawdę możliwe i prawdopodobnie wymagałoby porównania określonych oświadczeń, jeśli faktycznie ma znaczenie.

Zazwyczaj jednak warto użyć poprawnej instrukcji i nie martwić się o nią, ponieważ zazwyczaj nie ma możliwości wyboru między AKTUALIZACJĄ a WSTAW.

Answer 3

To zależy. Jeśli aktualizacja nie wymaga zmiany klucza, najprawdopodobniej będzie to kosztować tylko wyszukiwanie, a prawdopodobnie koszt będzie niższy niż wkładka, chyba że baza danych jest zorganizowana jak kupa.

Jest to jedyna myśl, którą mogę wyrazić, ponieważ wyniki znacznie zależą od zastosowanej organizacji bazy danych.

Jeśli na przykład korzystasz z MyISAM, który, jak przypuszczam, jest zorganizowany jak isam, wstawka powinna generalnie kosztować to samo, jeśli chodzi o dostęp do odczytu bazy danych, ale będzie wymagać dodatkowej operacji zapisu.

Answer 4

Nie można porównać INSERT i UPDATE w ogóle. Podaj przykład (z definicją schematu), a wyjaśnimy, który z nich kosztuje więcej i dlaczego. Możesz także wybrać konkretny INSERT i UPDATE, sprawdzając swój plan i czas wykonania.

Niektóre zasady rekomendacji mimo:

• jeśli tylko aktualizować tylko jedno pole, które nie są indeksowane i aktualizować tylko jeden rekord i użyć rowid/klucz podstawowy, aby znaleźć ten rekord wtedy ta aktualizacja będzie kosztować mniej niż
• INSERT, który będzie również dotyczył tylko jednego wiersza, chociaż ten wiersz będzie miał wiele niepowiązanych, indeksowanych pól o wartości zerowej; i wszystkie te indeksy muszą być zachowane (np. dodać nowy listek)

Answer 5

Na serwerze Sybase/SQL Server aktualizacja, która wpływa na kolumnę z indeksem tylko do odczytu, jest wewnętrznie zastępowana przez usunięcie, a następnie wstawienie, więc jest to oczywiście wolniejsze niż wstawianie. Nie znam implementacji dla innych silników, ale myślę, że jest to wspólna strategia przynajmniej wtedy, gdy zaangażowane są indeksy. Teraz tabele bez indeksów (lub dla żądań aktualizacji nie zawierających indeksu) Przypuszczam, że są przypadki, w których aktualizacja może być szybsza, w zależności od struktury tabeli.

Answer 6

Kluczowym zasobem jest tu dostęp do dysku (dokładniej IOPS), a my powinniśmy ocenić, które z nich wynikają z minimum.

Zgadzam się z innymi na temat tego, jak niemożliwe jest udzielenie ogólnej odpowiedzi, ale kilka myśli, które poprowadzą Cię we właściwym kierunku, zakładają prosty magazyn wartości klucz-wartość i indeks jest indeksowany. Wstawienie wstawia nowy klucz, a aktualizacja aktualizuje wartość istniejącego klucza.

Jeśli tak jest (bardzo często), aktualizacja będzie szybsza niż wstawienie, ponieważ aktualizacja obejmuje indeksowane wyszukiwanie i zmianę istniejącej wartości bez dotykania indeksu. Można założyć, że jest to jeden dysk odczytany w celu uzyskania danych i prawdopodobnie jednego zapisu na dysku. Z drugiej strony wstawienie wymagałoby dwóch zapisów na dysku jednego dla indeksu, drugiego dla danych. Kolejnym ukrytym kosztem jest dzielenie węzłów btree i tworzenie nowych węzłów, które miałyby miejsce w tle, podczas gdy wstawianie prowadziłoby średnio do większego dostępu do dysku.

Answer 7

Jeśli planujesz przeprowadzić duże przetwarzanie (takie jak ocena lub fakturowanie dla firmy komórkowej), to pytanie ma ogromny wpływ na wydajność systemu.

Przeprowadzanie aktualizacji na dużą skalę w porównaniu z wieloma nowymi tabelami i indeksem sprawdziło się, że mój proces rozliczeniowy firmy zmniejszył się z 26 godzin do 1 godziny!

Próbowałem na 2 milionach rekordów dla 100 000 klientów. Najpierw utworzyłem tabelę rozliczeniową, a następnie wszystkie wywołania podsumowań klientów, zaktualizowałem tabelę rozliczeniową o czas trwania, cenę, rabat .. w sumie 10 pól.

W drugiej opcji utworzyłem 4 fazy. Każda faza odczytuje poprzednią tabelę (tabele), tworzy indeks (po wstawieniu wstawionej tabeli) i używając: "wstaw do od wyboru .." Stworzyłem następną tabelę dla następnej fazy.

Podsumowanie Chociaż drugiej alternatywy wymaga znacznie więcej miejsca na dysku (wszystkie widoki i tabele tymczasowe usunięty na końcu) Istnieją 3 główne zalety tej opcji: 1. To było 4 razy szybsze niż wariant 1. 2. W przypadku, gdy wystąpił problem w trakcie procesu, mogłem rozpocząć proces od momentu, w którym się nie powiódł, ponieważ wszystkie tabele na początku fazy były gotowe i proces mógł zostać uruchomiony ponownie od tego momentu. Jeśli proces nie powiedzie się za pomocą pierwszej opcji, należy rozpocząć cały proces od nowa. 3. Dzięki temu prace rozwojowe i kontroli jakości przebiegały znacznie szybciej, ponieważ mogły działać równolegle .