die schnellste möglichkeit zu prüfen, ob ein eintrag existiert

[EyeDacor]

mehrere anwendungen :)

[dachris]

Kommt nat. auf die Komplexität der anfragen an....

Aber im Prinzip sollte das kein Problem sein....

Wenn die Queries optimiert sind, kannst du auch an ein Halten der Datenbank im Speicher denken.....Das boostet die Datenbank nochmal um einiges (Aber dazu brauchst du wohl einen rootServer....)

Auch ein Caching der Queries macht Sinn.....

Meistens verändern sich viele Ergebnisse der Abfragen nicht....

Dann noch einige Tips

Auf Spielzeug wie who is online und so'n Zeug oder dynamische Ausgabe von countern verzeichten...
Dann können manche Schreibzugriffe beseitigt werden....
d.h. Userlogging in der Datenbank macht keinen Sinn.....Schreibzugriffe auf Dateien sind performanter....
Also einfach das SQLstatement in eine Datei schreiben....und dann via cron jede Stunde oder pro Tag in die Datenbank schreiben.....
Dann auf Datenbanksessions verzeichten....updates sind prinzipiell langsam....
Dann auf joins verzichten (langsam)
Ein generelles Caching von dynamischen Seiten bedenken.....(welche Inhaltsseite muss denn wirklich dynamisch on the fly generiert werden)


Naja wenn man das so halbwegs berücksichtigt dann laufen auch bedeutend mehr queries locker ab.....

[Gweilo]

Habe jetzt nicht alles ganz genau durchgelesen, aber hast du mal probiert alles in ein query anzugeben? Die Datenbank kann dann viel besser optimieren und muss nicht für jedes query eine Verbindung aufbauen.

Ich kenne ja deine genauen insterts nicht, aber eventuell könntest du die von der anderen Tabelle gleich reinnehmen.

Also sowas in dem Stil:

INSERT INTO tabelle (a,b,c) VALUES (
    SELECT (d, e, f) 
    FROM tabelle2
    WHERE my_string IN (
        SELECT ein_string FROM andere_tabelle
    )
);

edit:
ansonsten gäbe es da noch WHERE exists

Hier ein Codebeispiel

SELECT t.Name
FROM Tabelle t
WHERE NOT EXISTS (
    SELECT *
    FROM AndereTabelle a
    WHERE a.Text = t.Text)

Not in ist aber optimierungstechnisch besser, da diese Anfrage unkorreliert ist (muss nicht mehrfach ausgewertet werden), im Gegensatz zu EXISTS

[EyeDacor]

danke gweilo, das problem hat sich aber mittlerweise gelöst. :)

@ dachris: danke für die tip(p)s, jedoch habe ich mit derartigen sachen bei meiner anwendung nichts zu tun (irgendeine seite mit sachen wie "who is online" und so nen kram)

es ist eine anwendung, die auf eine bestehendes netzwerkprotokoll zugreift und daten auswertet... da versteht man das 'komplette' rfc, hat etwa ein halbes jahr planung, testing und entwicklung, und dann kommen einen sachen wie mysql/performance in den weg... das 'nervt' schon etwas ^^

wie gesagt, thema erledigt und nochmal danke an alle beteiligten und den hint auf UNIQUE :)

[feuervogel]

> Dann auf joins verzichten (langsam)

schon mal mit subqueries gearbeitet? das verhältniss von subquery zu join ist wie trabi zu ferrari...und wie will man auf joins verzichten, bei einer einigermaßen nicht-redundanten datenbankstruktur?

[dachris]

join ist ein nettes feature......nur eben langsam....(Klar subs sind noch langsamer)...

d.h. man muss sich immer die Frage stellen, brauchts das wirklich (bei jedem Aufruf) oder kann ichs nicht mit intelligenten Cachingmechanismen lösen....

d.h. ich will join nicht verbannen sondern die Frage in den Raum werfen obs jedesmal nötig ist....

Es kommt halt immer auf die Dynamik der DAten an....

d.h. Daten (also auch die Abfrragen danach) welche sich so gut wie nie verändern.....oder z.B. Suchabfragen lassen sich wunderbar cachen....

Nehmen wir als einfaches Beispiel die Abfrage nach einem Profil in einem Forum....

Da wird aus 5 verschiedenen Tabellen (user, gruppe, evtl anschrift, letzte Beiträge) jedesmal eine Abfrage gestartet.... Die gesamte Abfrage ist also bis zur Veränderung dieser Daten immer die gleiche....wird aber trotzdem immer in der Gesamtheit ausgeführt....

Jetzt könnte man hergehen und beim ersten mal die Userdaten(user, gruppe, anschrift) nach der Abfrage in eine Datei schreiben, die Datei heisst dann wie die Abfrage nur mit md5 überschlüsselt....
Das Speicherformat könnte z.B. xml sein...oder was auch immer

jetzt muss nur noch eine einige Abfrage stattfinden nach den letzten Beiträgen....(wobei die natürlich auch cachebar ist....)

So hat man aus einem langen join eine einzige performante Abfrage gemacht