Optimeret sletning af dublerede rækker

er der index paa artid felterne ?

hvis nyere MySQL kan du bruge en WHERE IN subquery

Ja, der er index på artID. Hvad mener du med WHERE IN?

DELETE FROM artikel2 WHERE artid IN (SELECT artid FROM artikel)

Den ser jo meget fornuftig ud. Jeg kan ikke lige se om performance skulle være bedre, fordi jeg får følgende fejl:
#1064 - You have an error in your SQL syntax.  Check the manual that corresponds to your MySQL server version for the right syntax to use near 'SELECT artID FROM artikel)' at line 3

hvilken version af MySQL ?

Det er version 4.0.26.

31/08-2006 21:25:42 syntax kraever 4.1 eller nyere

Surt show :) Ved du om din sætning yder bedre performance end min egen. For i givet fald vil jeg opgradere til ver. 5

Svjv. er det vist kun selve subselect'en, som kræver 4.1 eller nyere. Man kan bruge selve IN-syntaksen i tidligere versioner.

Man burde derfor kunne tage 31/08-2006 21:25:42 og modifisere den sådan at subselect'en håndteres i PHP i stedet for i SQL:

$sql = "SELECT artid FROM artikel";
$result = mysql_query($sql) or die(mysql_error());

$inArr = array();
while ($row = mysql_fetch_assoc($result)) {
    $inArr[] = $row["artid"];
}
$in = join(",", $inArr);

if ($in != "") {
    $sdql = "DELETE FROM artikel2 WHERE artid IN ($in)";
    mysql_query($sql) or die(mysql_error());
}

en MySQL 4.0 trænger til en opdatering !

m.h.t. IN og seubquery er det helt korrekt

så det kan løses på den måde i PHP (omend det kan blive en meget lang SQL
sætning ved store data)

Nu er den (altså 4.0.26) vel heller ikke *så* gammel - kun ca. 2 år:

http://dev.mysql.com/doc/refman/4.1/en/news-4-0-26.html

Men, ja der er da bestemt en masse fordele ved at opgradere til 5.0.x:

http://www.mysql.org/doc/refman/5.0/en/news-5-0-24.html

Det er jo bare ikke sikkert at pct har muligheden for dette, f.eks. hvis det er på et webhotel.

det tredie tal er jo ikke ny funktionalitet kun bug fixes

4.0 gik i public test i 2001 og i production i 2003

der er 2 nye versioner i production 4.1 og 5.0 med 5.1 i public test

de fleste af de "gode ting" kom i 4.1 og ikke i 4.0

derfor syne sjeg at det var en god ide at opdatere

som web hotel kunde hænger man på deres MySLQ version - og der er stadig nogen som kører 3.23.x

men jeg tolkede 03/09-2006 09:48:18 som at spørger kunne opdatere

og der er rigtigt mange SQL mæssige fordele ved at opdatere fra 4.0

Fuldstændig enig. :^)

Tak for jeres indlæg, jeg opgraderer til ver. 5.
Smidder i lige et svar, så jeg kan give jer point.

Btw. mener I, at Nielle's udlægning yder bedre performance end min egen "WHERE artikel2.artID = artikel.artID"?

03/09-2006 10:43:21 ?

måske - prøv det !

og svar

Jeg er ret sikker på at den giver bedre performance end dit nuværende. Men, prøv endelig at afprøve det selv. Det er den slags eksperimenter man lære mest af. :^)

Arne_v har ret i at det kan blive en meget stor IN-del, hvis du har mange rækker i artikel-tabellen. Jeg er dog ikke sikker på at dette koster specielt meget på performance (men måske skulle jeg afprøve det selv. Det er den slags eksperimenter man lære mest af. ;^)

Bortset fra det, så er der ganske gode grunde til generelt at opdatere til 5.

Siden at du anvender arne_v's løsning på denne her, står jeg bare over på point. Men ellers tak for tilbudet. :^)

Der er temlig mange rækker, og det er lidt af et arbejde at opg. til ver 5. Men jeg kan forstå på jer, at det er det værd.
Tak for hjælpen begge to.