INSERT INTO SELECT mit ON DUPLICATE KEY

[prego]

Hi,

finde gerade nichts, was das erklärt. Vielleicht könnt ihr mir helfen:

INSERT INTO tab1 

SELECT 
feld1 AS quelle1,  //bezieht sich auf tab2
feld2 AS quelle2,

FROM tab2 

ON DUPLICATE KEY 

UPDATE 
feld1 = quelle1  //bezieht sich auf tab1

Ohne DUPLICATE KEY funzt die Sache tadellos.
Wie referenzier ich den Inhalt der Select-Query richtig für das Update bie ON DUPLICATE KEY?


//edit:
In the values part of ON DUPLICATE KEY UPDATE, you can refer to columns in other tables, as long as you do not use GROUP BY in the SELECT part. One side effect is that you must qualify non-unique column names in the values part.

hmm. Ich hab in meinem Select ein GROUP BY. Gibt es also dann keine Möglichkeit mit ON DUPLICATE KEY zu arbeiten, oder muss ich dann nur anders referenzieren?

[wahsaga]

Re: INSERT INTO SELECT mit ON DUPLICATE KEY

Tut's in so einem Falle nicht ein REPLACE?

[ZombieChe]

Soweit ich weiß referenziert man mit mit VALUES in der UPDATE Anweisung.
VALUES(feld1)
Habs aber noch in Verbindung mit SELECT benutzt also einfach mal probieren^^

[prego]

REPLACE tuts, danke.

Hab nur immer INSERT ON DUPLICATE KEY vorgezogen, weil da kein kompletter Table-Scan gemacht werden muss bei jeder Zeile. Es wird ja "quasi" der Error vom duplicate-key ausgewertet.

Mit Values das hab ich leider nicht hinbekommen. Kommt immer nen Fehler in der Values Klammer.


Dank euch beiden.

[wahsaga]

Wieso kompletter Table-Scan?
Auch REPLACE orientiert sich doch nur am primary Key bzw. definierten unique indexes.

[prego]

INSERT ON DUPLICATE KEY UPDATE Inserted erst, stellt dann anhand der Keys fest "oh, hab ja schon son key" und macht dann en update. Replace sucht quasi vor jeder Aktion erst nach einer passenden Key-Kombination und entscheidet dann ob es Updaten oder Inserten muss.

Hab mal ne Tabelle mit 30Mil Zeilen gehabt. Nach der Umstellung auf INSERT ON DUPLICATE war der Server nur noch ein viertel belastet. Hab leider kein Bild mehr vom munin davon.

[mrhappiness]

Original geschrieben von prego
Replace sucht quasi vor jeder Aktion erst nach einer passenden Key-Kombination und entscheidet dann ob es Updaten oder Inserten muss.

Passt aber nicht zur Beschreibung

REPLACE works exactly like INSERT, except that if an old row in the table has the same value as a new row for a PRIMARY KEY or a UNIQUE index, the old row is deleted before the new row is inserted. See Section 13.2.4, “INSERT Syntax”.

REPLACE is a MySQL extension to the SQL standard. It either inserts, or deletes and inserts. For another MySQL extension to standard SQL — that either inserts or updates — see Section 13.2.4.3, “INSERT ... ON DUPLICATE KEY UPDATE Syntax”. INSERT ... ON DUPLICATE KEY UPDATE is available as of MySQL 4.1.0.

...

MySQL uses the following algorithm for REPLACE (and LOAD DATA ... REPLACE):

1.

Try to insert the new row into the table
2.

While the insertion fails because a duplicate-key error occurs for a primary key or unique index:
1.

Delete from the table the conflicting row that has the duplicate key value
2.

Try again to insert the new row into the table

Quelle: http://dev.mysql.com/doc/refman/5.0/en/replace.html

[prego]

Hmm,

macht Sinn. Nur warum habe ich das so ne Performance Steigerung gehabt bei der Umstellung von Replace auf Insert on Duplicate Key Update?

[wahsaga]

Original geschrieben von prego
INSERT ON DUPLICATE KEY UPDATE Inserted erst, stellt dann anhand der Keys fest "oh, hab ja schon son key" und macht dann en update.

Wie soll das gehen?

Wenn ein INSERT, das ein unique key constraint verletzten würde, zunächst mal ausgeführt würde, wär's doch schon zu spät, und die Datenintegrität schon im Ar***.

Hast du einen Beleg für die Behauptung, dass so verfahren würde?

[prego]

Wie gesagt, das hab ich leider nicht...

Momentan erreiche ich auch denjenigen nicht, der mir das damals empfohlen hat. Sowie ich ihn erreichen, melde ich mich aber nochmal.