Re: Speed - REPLACE <-> UPDATE

[Martin Ramsch <m.ramsch_(at)_computer.org>]

Thomas Heller schrieb am Mittwoch, den  4. August 1999:
> Was ist nun schneller?
> 1. "REPLACE INTO table VALUES (id, NULL, new_int);"
> 2. "UPDATE table SET state=new_int WHERE id=id;"
> 
> Falls jemand von euch hier mehr Erfahrung haben sollte wäre ich ihm
> für eine Antwort sehr dankbar!

Erfahrung nicht, aber aus eigenem Interesse heraus selbst
ausprobiert.

Einfach eine Textdatei mit SQL-Befehlen erstellen, diese zum Test
mehrfach mit "mysql" abarbeiten und die Zeit messen.  Die Testtabelle
hatte dabei _nur_ die drei Felder, die Du in Deiner Mail zitierst:
   CREATE TABLE t (
     id varchar(32) DEFAULT '' NOT NULL,
     last_update timestamp(14),
     state int(10) unsigned DEFAULT '0' NOT NULL,
     PRIMARY KEY (id)
   );

a) 5000-mal die Zeilen:
     UPDATE t SET state=31 WHERE id='abcd';
     UPDATE t SET state=30 WHERE id='abcd';

b) 5000-mal die Zeilen:
     REPLACE INTO t VALUES ('abcd', NULL, 30);
     REPLACE INTO t VALUES ('abcd', NULL, 31);

Das ganze hab' ich dann je 30-mal laufen lassen und die Zeiten
gemittelt, wobei die absoluten Zahlen ja egal sind (hängt alles von
meinem konkreten System ab), sondern nur der relative Vergleich zählt:

a) UPDATE  brauchte im Schnitt 14.54s (pro 10000 Ausführungen)
b) REPLACE brauchte im Schnitt 13.97s (pro 10000 Ausführungen)

Folglich ist bei dieser konkreten Anwendung REPLACE minimal schneller
als UPDATE (um etwa 4%).

Falls Du allerdings mehrere solche Aktualisierungen auf einen Schlag
machen kannst und die betroffenen Datensätze also zusammen mit einer
einzigen REPLACE-Anweisung abschickst, dann ist REPLACE _deutlich_
schneller.

c) Die eine superlange Anweisung:
     REPLACE INTO t VALUES
      ('abcd', NULL, 1)
     ,('abcd', NULL, 2)
     ,('abcd', NULL, 3)
     ,[...bis...] 10000);

   Das braucht über 30 Test gemittelt nur je 4.05s!

Bei breiteren Tabellen, wo man bei REPLACE deutlich mehr Daten
mitschleppen müßte (nämlich die Werte der anderen Felder), werden sich
die Ergebnisse vermutlich wieder zu Gunsten von UPDATE verschieben.

Ciao,
  Martin
-- 
Martin Ramsch <m.ramsch_(at)_computer.org> <URL: http://home.pages.de/~ramsch/ >
PGP KeyID=0xE8EF4F75 FiPr=52 44 5E F3 B0 B1 38 26  E4 EC 80 58 7B 31 3A D7

---
*** Abmelden von dieser Mailingliste funktioniert per E-Mail
*** an mysql-de-request_(at)_lists.4t2.com mit Betreff/Subject: unsubscribe