From iukaccent at seh.com Tue Oct 23 08:07:23 2007
From: iukaccent at seh.com (Hazel Raines)
Date: Tue, 23 Oct 2007 16:07:23 +1000
Subject: ***SPAM*** Energy fur ihren Schwanz, kaufen und 85% sparen
Message-ID: <01c8158e$cc066690$da1cf0dc@iukaccent>
Sie leben nur einmal - warum dann nicht was neues ausprobieren?
Original - 100% wirksam
Ciiiaaaaaalis 10 Pack. 26,99 Euro
Viiiaaaagra 10 Pack. 20,99 Euro
- Diskrete Verpackung und Zahlung
- Kein peinlicher Arztbesuch erforderlich
- Kostenlose, arztliche Telefon-Beratung
- Kein langes Warten - Auslieferung innerhalb von 2-3 Tagen
- Bequem und diskret online bestellen.
- Visa verifizierter Onlineshop
- keine versteckte Kosten
Mit unseren Produkten vergessen Sie Ihre Enttauschungen, anhaltende Versagensangste und wiederholte peinliche Situationen
Vier Dosen gibt's bei jeder Bestellung umsonst
(bitte warten Sie einen Moment bis die Seite vollstandig geladen wird)
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://lists.mushaake.org/pipermail/mysql-de/attachments/20071023/2ce2f5e0/attachment.html
From tobias at gfz-potsdam.de Thu Oct 25 17:24:35 2007
From: tobias at gfz-potsdam.de (Tobias Mueller-Wrana)
Date: Thu, 25 Oct 2007 17:24:35 +0200
Subject: Newbie: Replikation etwas anders/komplizierter...
Message-ID: <4720B533.9030409@gfz-potsdam.de>
Hallöchen,
ich habe erfoglreich ein Replikations-System (Master-Slave) aufgezogen.
Nun möchte ich folgendes umsetzen (da die Datenbank sehr schnell sehr
voll läuft - hohe Perfomance)
Ein Haupt MySQL-Server soll Daten der letzten 7 Tage vorrätig halten.
Ein zweiter MySQL-Server soll ALLE Daten vorrätig haben.
So weit so gut & einfach ;-) Doch sollen beide zu jedem Zeitpunkt
aktuell sein.
Was in den 1. geschrieben/gelöscht wird, soll auch in den 2.
geschrieben/gelöscht
werden...
MASTER (7 Tage) und SLAVE (alle Daten) geht nicht, da ich alle Daten,
die älter
als 7 Tage sind, auch auf dem SLAVE verliere...(-> Replikation)
MASTER (alle Daten) und SLAVE (7 Tage) geht nicht, da die Replikation nicht
in "Echtzeit" vollzogen wird und es dann zu ungewollten Verzögerungen beim
Slave kommt.
Ist ein Cluster die einzige Alternative??? Oder gäbe es eine MASTER (7 Tage)
und SLAVE (alle Daten) Option, in der die Daten auf dem Slave, die älter
als 7 Tage
sind, NICHT gelöscht werden (über Rechte Managment)!?
--
Tobias
------------------------------
Tobias Mueller-Wrana
GFZ Potsdam, Sektion 2.4, E251
Telegrafenberg. D-14773 Potsdam
Tel.: +49-(0)331-288-1241
-------------------------------
_______________________________________________
Allgemeine Infos zur Liste: http://www.4t2.com/mysql/
Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de
From mysql at universalware.de Thu Oct 25 17:52:30 2007
From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=)
Date: Thu, 25 Oct 2007 17:52:30 +0200
Subject: Newbie: Replikation etwas anders/komplizierter...
In-Reply-To: <4720B533.9030409@gfz-potsdam.de>
References: <4720B533.9030409@gfz-potsdam.de>
Message-ID: <05e701c8171f$0cf0c5b0$8119fea9@nbandreas>
Hallo Tobias,
die Frage die sich mir hier sofort stellt ist: Was bedeutet "voll läuft".
Ich habe noch keine MySQL Datenbank gesehen die abgesehen vom verfügbaren
Plattenplatz vollgelaufen wäre.
Eine MySQL interne Lösung für deine Idee gibt es so nicht. Da ich aber zu
wenig vom eigentlichen Problem weiss kann ich auch keinen alternativen
Vorschlag machen.
Gruß,
Andreas
_______________________________________________
Allgemeine Infos zur Liste: http://www.4t2.com/mysql/
Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de
From tobias at gfz-potsdam.de Thu Oct 25 17:58:32 2007
From: tobias at gfz-potsdam.de (Tobias Mueller-Wrana)
Date: Thu, 25 Oct 2007 17:58:32 +0200
Subject: Newbie: Replikation etwas anders/komplizierter...
In-Reply-To: <05e701c8171f$0cf0c5b0$8119fea9@nbandreas>
References: <4720B533.9030409@gfz-potsdam.de>
<05e701c8171f$0cf0c5b0$8119fea9@nbandreas>
Message-ID: <4720BD28.2020002@gfz-potsdam.de>
Hallo Andreas,
also mit >>voll laufen<< meine ich, dass Abfragen bei einer vollen Datenbank
zu lange dauern. Ich spreche hier von Antworten von wenigen Skunden bis
max. 1 min. Wenn das System 1 Woche läuft, wird die Antwortzeit sichtlich
langsamer. Daher der Wunsch nach einer >>7 Tages<< Datenbank und wegen
der kostbaren Daten eine >>vollständige<< Datenbank. Beide sollen aber immer
auf dem aktuellsten Stand sein. Ich hatte daher an Replikation gedacht...
> die Frage die sich mir hier sofort stellt ist: Was bedeutet "voll läuft".
> Ich habe noch keine MySQL Datenbank gesehen die abgesehen vom verfügbaren
> Plattenplatz vollgelaufen wäre.
>
Bin auch für "tolle" Cronjob / Skript Lösungen zu haben. Jedoch scheidet ein
>>Datenbank runterfahren<< aus...
--
Tobias
------------------------------
Tobias Mueller-Wrana
GFZ Potsdam, Sektion 2.4, E251
Telegrafenberg. D-14773 Potsdam
Tel.: +49-(0)331-288-1241
-------------------------------
_______________________________________________
Allgemeine Infos zur Liste: http://www.4t2.com/mysql/
Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de
From ks at codebiz.de Thu Oct 25 18:03:32 2007
From: ks at codebiz.de (Kai Szymanski)
Date: Thu, 25 Oct 2007 18:03:32 +0200
Subject: Newbie: Replikation etwas anders/komplizierter...
In-Reply-To: <4720BD28.2020002@gfz-potsdam.de>
References: <4720B533.9030409@gfz-potsdam.de> <05e701c8171f$0cf0c5b0$8119fea9@nbandreas>
<4720BD28.2020002@gfz-potsdam.de>
Message-ID: <4720BE54.3030202@codebiz.de>
Hallo Tobias!
Auf was (Raid ? Einzelne Festplatte ?) liegt Deine Datenbank. Wenn auf
einem Raid, was für ein Raidtyp ? Es kommt auch ganz stark darauf an,
wie Deine Tabelle und Daten aussehen und mit was für Abfragen die der
Datenbank kommst. We need more Input ;)
CU,
Kai.
_______________________________________________
Allgemeine Infos zur Liste: http://www.4t2.com/mysql/
Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de
From tobias at gfz-potsdam.de Thu Oct 25 18:09:20 2007
From: tobias at gfz-potsdam.de (Tobias Mueller-Wrana)
Date: Thu, 25 Oct 2007 18:09:20 +0200
Subject: Newbie: Replikation etwas anders/komplizierter...
In-Reply-To: <4720BE54.3030202@codebiz.de>
References: <4720B533.9030409@gfz-potsdam.de> <05e701c8171f$0cf0c5b0$8119fea9@nbandreas> <4720BD28.2020002@gfz-potsdam.de>
<4720BE54.3030202@codebiz.de>
Message-ID: <4720BFB0.2050901@gfz-potsdam.de>
Hallo Kai,
die MySQL DB läuft noch auf einem StandAllone System (SuSE 10.2).
Wir sind offen, für andere System. Folgende Ansprüche haben wir:
- Schnelle Queries fuer das operationale Echtzeitsystem (~ 1 Woche)
- Verfuegbarkeit aller Daten auf moeglichst lange Dauer
- beide System stets aktuell
> Auf was (Raid ? Einzelne Festplatte ?) liegt Deine Datenbank. Wenn auf
> einem Raid, was für ein Raidtyp ? Es kommt auch ganz stark darauf an,
> wie Deine Tabelle und Daten aussehen und mit was für Abfragen die der
> Datenbank kommst. We need more Input ;)
>
Die Replikations-Idee basiert bisher nur auf meinen Überlegungen.
Daher sind wir, was die Umsetzung angeht sehr offen (->CODA etc.).
--
Tobias
------------------------------
Tobias Mueller-Wrana
GFZ Potsdam, Sektion 2.4, E251
Telegrafenberg. D-14773 Potsdam
Tel.: +49-(0)331-288-1241
-------------------------------
_______________________________________________
Allgemeine Infos zur Liste: http://www.4t2.com/mysql/
Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de
From mysql at universalware.de Thu Oct 25 18:29:43 2007
From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=)
Date: Thu, 25 Oct 2007 18:29:43 +0200
Subject: Newbie: Replikation etwas anders/komplizierter...
In-Reply-To: <4720BD28.2020002@gfz-potsdam.de>
References: <4720B533.9030409@gfz-potsdam.de><05e701c8171f$0cf0c5b0$8119fea9@nbandreas>
<4720BD28.2020002@gfz-potsdam.de>
Message-ID: <061101c81724$400155f0$8119fea9@nbandreas>
Hallo Tobias,
also wie schon sicher gesehen da fehlt einfach noch ne Menge Info:
- Art der Daten und Art des Anfalls
- Art der Abfrage
- Anzahl Datensätze
- Datenvolumen
Ich kann dir verraten ich habe z.B. bei einem Kunden eine Datenbank (InnoDB,
rund 60 GB Daten) mit eine Tabelle mit über 100 Millionen Datensätzen auf
der man in Echtzeit arbeiten kann. Daher glaube ich weniger an ein MySQL
Performance Problem sondern vorerst an ein konzeptionelles Problem. Denn
eins muss man MySQL lassen - es ist auch geicher Hardware im vergleich zu
anderen System nun wirklich flott.
Gruß,
Andreas
_______________________________________________
Allgemeine Infos zur Liste: http://www.4t2.com/mysql/
Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de
From lists at sebastianmendel.de Thu Oct 25 20:14:21 2007
From: lists at sebastianmendel.de (Sebastian Mendel)
Date: Thu, 25 Oct 2007 20:14:21 +0200
Subject: Newbie: Replikation etwas anders/komplizierter...
In-Reply-To: <4720B533.9030409@gfz-potsdam.de>
References: <4720B533.9030409@gfz-potsdam.de>
Message-ID: <4720DCFD.3030600@sebastianmendel.de>
Tobias Mueller-Wrana schrieb:
> Hallöchen,
>
> [...] da die Datenbank sehr schnell sehr voll läuft - hohe Perfomance)
> Ein Haupt MySQL-Server soll Daten der letzten 7 Tage vorrätig halten.
> Ein zweiter MySQL-Server soll ALLE Daten vorrätig haben.
hast du schon mal an eine MERGE Tabelle gedacht?
tabelle1 mit den 7-Tage Daten
tabelle2 mit den 'alten'
eine MERGE tabelle über beide obige
und ein nächtliches script welches die 'alt gewordenen' Daten aus Tabelle 1
in Tabelle 2 verschiebt
dann kannst du entweder die aktuellen, die alten oder alle daten abfragen
... wobei die MERGE Tabelle auch durch UNION zu lösen wäre ...
aber wie auch die anderen schrieben würde ich eher erstmal die Abfragen und
das Db-Design überprüfen ...
--
Sebastian
_______________________________________________
Allgemeine Infos zur Liste: http://www.4t2.com/mysql/
Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de
From tobias at gfz-potsdam.de Fri Oct 26 09:15:30 2007
From: tobias at gfz-potsdam.de (Tobias Mueller-Wrana)
Date: Fri, 26 Oct 2007 09:15:30 +0200
Subject: LAYOUT Re: Newbie: Replikation etwas anders/komplizierter...
In-Reply-To: <061101c81724$400155f0$8119fea9@nbandreas>
References: <4720B533.9030409@gfz-potsdam.de><05e701c8171f$0cf0c5b0$8119fea9@nbandreas> <4720BD28.2020002@gfz-potsdam.de>
<061101c81724$400155f0$8119fea9@nbandreas>
Message-ID: <47219412.4040008@gfz-potsdam.de>
Hallo Ihr,
Also etwas zum Layout (kann man hier auch Dateien anhängen?):
Es sind ca. 42 Tabellen mit je ca. 20 Variablen. Es sind Metadaten aus
den Bereichen strings, double, ints usw. Keine Binärdateien.
Die Abfrage läuft über vorgefertigte Wrappe in C.
Ich habe die DB ca. 'ne knappe Woche laufen lassen, Dabei entstand ein
Datenvolumen von knapp 5-10GB. a) sind wir bemüht diese auszumisten,
d.h. man könnte das Volumen evtl. auf 3-5GB pro Woche reduzieren
b) wenn man das für ein paar Monate / Jahre hoch rechnet.... :-(
Aus diesem Grund wollten wir ja eine "7 Tages" Datenbank.
Eine extrem lang laufende Abfrage (so in der Art) als Bsp.:
select * from Tabelle1, Tabelle2 where Tabelle1.id=Tabelle2.id and
Tabelle2.id not in (select distinct(id) from Tabelle3);
Anmerkung: Das ist die Abfrage, die wir bräuchten um den "Müll"
aus der DB zu entfernen... (Alles was in T1 & T2 ist, aber nicht mit
T3 assoziiert, soll raus). Sie dauert ein paar Stündchen *gähn* und
legt somit das Echtzeitproblem lahm.
@Sebastian: Das konzeptionelle Problem(?) stammt a) nicht von mir und
b) wird schwierig sein es generell zu ändern. :-(
MERGE habe ich noch nicht ausprobiert. Werde mich mal belesen. Doch mit
einem nächtlichen Cronjob/Skript muss hoffentlich nicht die DB
runtergefahren
werden, denn sie muss 24/7 einsatzbereit sein.
Ist MERGE eine Liveupdate? Und ginge MERGE auch über mehrere Tabellen?
Wenn ja, könnte man die Replikation ja, über die 7 Tages Tabellen laufen
lassen?
--
Tobias
------------------------------
Tobias Mueller-Wrana
GFZ Potsdam, Sektion 2.4, E251
Telegrafenberg. D-14773 Potsdam
Tel.: +49-(0)331-288-1241
-------------------------------
_______________________________________________
Allgemeine Infos zur Liste: http://www.4t2.com/mysql/
Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de
From lists at sebastianmendel.de Fri Oct 26 10:03:32 2007
From: lists at sebastianmendel.de (Sebastian Mendel)
Date: Fri, 26 Oct 2007 10:03:32 +0200
Subject: LAYOUT Re: Newbie: Replikation etwas anders/komplizierter...
In-Reply-To: <47219412.4040008@gfz-potsdam.de>
References: <4720B533.9030409@gfz-potsdam.de><05e701c8171f$0cf0c5b0$8119fea9@nbandreas> <4720BD28.2020002@gfz-potsdam.de> <061101c81724$400155f0$8119fea9@nbandreas>
<47219412.4040008@gfz-potsdam.de>
Message-ID: <47219F54.5030805@sebastianmendel.de>
Tobias Mueller-Wrana schrieb:
> Eine extrem lang laufende Abfrage (so in der Art) als Bsp.:
>
> select * from Tabelle1, Tabelle2 where Tabelle1.id=Tabelle2.id and
> Tabelle2.id not in (select distinct(id) from Tabelle3);
ich kenn mich nicht 100% aus bei ... NOT IN (SELECT ...) aber ich würde
vermuten das MySQL es hier eher schwer hat den Index vernünftig zu verwenden ...
vielleicht wäre folgendes etwas schneller:
SELECT *
FROM Tabelle1
LEFT JOIN Tabelle2
USING (id)
LEFT JOIN Tabelle3
USING (id)
WHERE ISNULL(Tabelle3.id)
oder
HAVING ISNULL(Tabelle3.id)
> Anmerkung: Das ist die Abfrage, die wir bräuchten um den "Müll"
> aus der DB zu entfernen... (Alles was in T1 & T2 ist, aber nicht mit
> T3 assoziiert, soll raus). Sie dauert ein paar Stündchen *gähn* und
> legt somit das Echtzeitproblem lahm.
okay, nur um sicher zu sein, ein EXPLAIN hast du aber schonmal probiert?
und ich vermute mal die ganzen CACHE und Speichereinstellungen wurden schon
überprüft? (tmp_table_size, key_cache, sort_buffer, table_cache, ...)
> @Sebastian: Das konzeptionelle Problem(?) stammt a) nicht von mir und
> b) wird schwierig sein es generell zu ändern. :-(
>
> MERGE habe ich noch nicht ausprobiert. Werde mich mal belesen. Doch mit
> einem nächtlichen Cronjob/Skript muss hoffentlich nicht die DB
> runtergefahren
nein, ein ganz normales Script welches per SQL alte Daten in die andere
Tabelle verschiebt ...
> werden, denn sie muss 24/7 einsatzbereit sein.
> Ist MERGE eine Liveupdate? Und ginge MERGE auch über mehrere Tabellen?
> Wenn ja, könnte man die Replikation ja, über die 7 Tages Tabellen laufen
> lassen?
MERGE fasst mehrere identische MyISAM Tabellen zu einer zusammen
--
Sebastian
_______________________________________________
Allgemeine Infos zur Liste: http://www.4t2.com/mysql/
Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de
From mysql at universalware.de Fri Oct 26 10:45:15 2007
From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=)
Date: Fri, 26 Oct 2007 10:45:15 +0200
Subject: LAYOUT Re: Newbie: Replikation etwas anders/komplizierter...
In-Reply-To: <47219412.4040008@gfz-potsdam.de>
References: <4720B533.9030409@gfz-potsdam.de><05e701c8171f$0cf0c5b0$8119fea9@nbandreas> <4720BD28.2020002@gfz-potsdam.de><061101c81724$400155f0$8119fea9@nbandreas>
<47219412.4040008@gfz-potsdam.de>
Message-ID: <0aec01c817ac$87e143c0$8119fea9@nbandreas>
Hallo Tobias,
rein aus dem Bauch heraus würde ich hier folgendes vorschlagen:
Wie es scheint gibt es einen Input-Bereich und einen Lager-Bereich. Im Input
Bereich fallen Daten an nach einem Aufräumen in den Lager-Bereich überführt
werden müssen.
Also würde ich den Input Bereich so gestalten das er in möglichst für das
Aufräume greifbare Blöcke zerlegt wird und die Aufräumarbeiten in dem Input
Bereich noch überschaubar bleiben. z.B.
- pro Tag eine Tabelle
- am Ende es Tages die Tabelle aufräumen und Daten in Lager-Tabelle
schreiben
- nicht verarbeitete Daten (weil noch nicht aufräumbar) verschiebe ich in
die aktuelle Tagestabelle
- usw.
Damit halte ich den Input Bereich klein, was ich aufräumen kann Räum ich
auf, was nicht verarbeitbar ist verschiebe ich auf den nächsten Zyklus.
"Tag" kann man nun auch als 2 Tage, Woche, Monat o.ä. auffassen.
Das Aufräumen, Übertragen in Lagertabelle und Säubern des Input Bereiches
muss dabei aber in einer Transaktion ablaufen - sprich MyISAM als Storage
Engine fällt da aus. Daher würde ich hier (vor allem bei den Datenmengen)
auf InnoDB setzen. Eine schönen fetten Datenbankserver nehmen (ordentlich
CPU, viel RAM und vor allem sehr schnelle Platten) und dem InnoDB ordentlich
Platz (auto extend bremst extrem also lieber gleich auf Partition schrieben
lassen oder ordentlich große Tablespace Dateien anlegen) und RAM geben.
Evtl. reicht es wenn man den Input Bereich auf InnoDB fährt und die
Lager-Tabellen auf MyISAM aber das müsste man in der Praxis sehen wie sich
auch Abfragen gestalten denn: Fahre ich zwei vollausgebaute Storage-Engines
in MySQL brauch ich für bei jeweils viel RAM denn die Buffer, Caches etc.
gehören der jeweiligen Storage Engine.
Noch kurz zum Aufräumen: Das Aufräumen nach der Methode von Sebastian ist
wesentlich schneller als der Subselect - da hat sich zwar in den 5er
Versionen viel am optimizer getan aber so richtig herausoptimieren von
solchen Abfragen klappt noch nicht ganz. Bei meinem Vorschlag würde das
ganze sogar nochmals vereinfach weil man hier direkt auf einen Inner-Join
setzen kann:
INSERT INTO lager_tabelle(felder....)
SELECT felder....
FROM Tabelle1
INNER JOIN Tabelle2 ON Tabelle2.ID=Tabelle1.ID
INNER JOIN Tabelle3 ON Tabelle3.ID=Tabelle2.ID
Schneller geht das dann nun wirklich nicht :-)
Gruß,
Andreas
_______________________________________________
Allgemeine Infos zur Liste: http://www.4t2.com/mysql/
Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de
From ks at codebiz.de Fri Oct 26 11:17:30 2007
From: ks at codebiz.de (Kai Szymanski)
Date: Fri, 26 Oct 2007 11:17:30 +0200
Subject: Newbie: Replikation etwas anders/komplizierter...
In-Reply-To: <4720BFB0.2050901@gfz-potsdam.de>
References: <4720B533.9030409@gfz-potsdam.de> <05e701c8171f$0cf0c5b0$8119fea9@nbandreas> <4720BD28.2020002@gfz-potsdam.de> <4720BE54.3030202@codebiz.de>
<4720BFB0.2050901@gfz-potsdam.de>
Message-ID: <4721B0AA.4010902@codebiz.de>
Hi!
Wir haben hier Datenbanken mit knapp 280 Mio. Datensätzen. Wichtig ist
unter anderem die Hardware (was für eine iowait habt Ihr, wenn die
Datenbank Deiner Meinung nach langsamer wird?). Du musst vor allem
Monitoren um herauszufinden, wo das Bottleneck liegt (Festplattensystem,
Speicher, Suboptimale Queries etc.). Wir setzen hier auf Server mit 16
GB Ram und einem DAS (Raid10 / SAS / 15 x 15.000er Festplatten). Ist gut
fix ;)
CU,
Kai.
_______________________________________________
Allgemeine Infos zur Liste: http://www.4t2.com/mysql/
Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de
From tobias at gfz-potsdam.de Fri Oct 26 12:27:36 2007
From: tobias at gfz-potsdam.de (Tobias Mueller-Wrana)
Date: Fri, 26 Oct 2007 12:27:36 +0200
Subject: LAYOUT Re: Newbie: Replikation etwas anders/komplizierter...
In-Reply-To: <47219F54.5030805@sebastianmendel.de>
References: <4720B533.9030409@gfz-potsdam.de><05e701c8171f$0cf0c5b0$8119fea9@nbandreas> <4720BD28.2020002@gfz-potsdam.de> <061101c81724$400155f0$8119fea9@nbandreas> <47219412.4040008@gfz-potsdam.de>
<47219F54.5030805@sebastianmendel.de>
Message-ID: <4721C118.5000401@gfz-potsdam.de>
WoW Sebastian,
> ich kenn mich nicht 100% aus bei ... NOT IN (SELECT ...) aber ich würde
> vermuten das MySQL es hier eher schwer hat den Index vernünftig zu verwenden ...
>
> vielleicht wäre folgendes etwas schneller:
>
> SELECT *
> FROM Tabelle1
> LEFT JOIN Tabelle2
> USING (id)
> LEFT JOIN Tabelle3
> USING (id)
> WHERE ISNULL(Tabelle3.id)
>
> oder
>
> HAVING ISNULL(Tabelle3.id)
>
Ich habe Deinen Befehl mal umgesetzt... WoW! Also der Unterschied
meine Befehl braucht Stunden *gähn* Deiner < 1min... Yepee
Super herzlichen Dank!!!!!
--
Tobias
------------------------------
Tobias Mueller-Wrana
GFZ Potsdam, Sektion 2.4, E251
Telegrafenberg. D-14773 Potsdam
Tel.: +49-(0)331-288-1241
-------------------------------
_______________________________________________
Allgemeine Infos zur Liste: http://www.4t2.com/mysql/
Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de