MYSQL-ABFRAGE SCHNELLER

[Nicole]

Hallo erst mal ;-)
ich nutze nachfolgende Querys um einen Überblick
zu bekommen/STATISTIK.

Es sind zwar mittlerweile 20.000 Datensätze,
aber dennoch sollte das nicht so langsam sein.

Vorweg schon mal:
1.Am Server liegts nicht
2. Auch anstatt mysql_affected_rows
   gleich z.B. select count(*) from...
   wird auch nicht schneller.
Fazit : Nein schneller wirds nur
wenn ich die Hälfte der Abfragen nehme.

BITTE:
Kann mir jemand sagen was ich falsch mache,
oder die unteren Abfragen in schneller umwandeln ?

//Anzahl User
$anz_u="select * from pro_db";
mysql_query("$anz_u");$anz_u=mysql_affected_rows();

//Anzahl User + einmal eingeloggt
$anz_ul="select * from pro_db where status ='1'";
mysql_query("$anz_ul");$anz_ul=mysql_affected_rows();

//Anzahl User + eingeloggt + F
$anz_ulf="select * from pro_db where status ='1'and icode !='x'";
mysql_query("$anz_ulf");$anz_ulf=mysql_affected_rows();

//Anzahl User + eingeloggt + E+F
$anz_ul2="select * from pro_db where status ='2'";
mysql_query("$anz_ul2");$anz_ul2=mysql_affected_rows();

//Anzahl User + eingeloggt + E+F+K
$anz_ul3="select * from pro_db where status ='3'";
mysql_query("$anz_ul3");$anz_ul3=mysql_affected_rows();

//Anzahl User gelöscht
$anz_del="select * from pro_db where status ='55'";
mysql_query("$anz_del");$anz_del=mysql_affected_rows();

//Anzahl neue Nachrichten
$anz_con="select * from pro_db_con where status ='0'";
mysql_query("$anz_con");$anz_con=mysql_affected_rows();

//Anzahl Empfehlungen
$anz_tell="select * from pro_db_tell";
mysql_query("$anz_tell");$anz_tell=mysql_affected_rows();

//Anzahl Empfehlungen eingetragen
$anz_tell2="select * from pro_db_tell where f_id !='0'";
mysql_query("$anz_tell2");$anz_tell2=mysql_affected_rows();

//Anzahl online zur zeit
$tx=(time() - 3600);
$anz_online="select * from pro_db where txi >='$tx'";
mysql_query("$anz_online");$anz_online=mysql_affected_rows();

[Harry]

Holladiewaldfee,

Es sind zwar mittlerweile 20.000 Datensätze,
aber dennoch sollte das nicht so langsam sein.

Oh doch ... wenn man nämlich ...

$anz_u="select * from pro_db";

... alle 20.000 Datensätze auf einmal ausliest.
Warum nicht einfach "SELECT COUNT(bla) AS anz_u FROM pro_db

$anz_ul="select * from pro_db where status ='1'";

Auch hier: "SELECT *" ist net sooo der Renner. Lieber "SELECT COUNT(nächstbestespalte)"

$anz_ulf="select * from pro_db where status ='1'and icode !='x'";

usw. usf.

Ciao,

Harry

[Nicole]

Hallo Harry,
du hast meine Frage nicht durchgelesen.

Da steht:
-------------------------------
2. Auch anstatt mysql_affected_rows
   gleich z.B. select count(*) from...
   wird auch nicht schneller.
------------------------------

Nikki

Holladiewaldfee,

Es sind zwar mittlerweile 20.000 Datensätze,
aber dennoch sollte das nicht so langsam sein.

Oh doch ... wenn man nämlich ...

... alle 20.000 Datensätze auf einmal ausliest.
Warum nicht einfach "SELECT COUNT(bla) AS anz_u FROM pro_db

Auch hier: "SELECT *" ist net sooo der Renner. Lieber "SELECT COUNT(nächstbestespalte)"

Harry

[Harry]

Holladiewaldfee,

du hast meine Frage nicht durchgelesen.

Doch. Nur zu schnell ;-)

Da steht:

2. Auch anstatt mysql_affected_rows
      gleich z.B. select count(*) from...
      wird auch nicht schneller.

---

Hab ich übersehn, sorry.

Hast Du passende Indizes in der Tabelle drin (siehe auch Michaels Frage)?

Ciao,

Harry

[Michael Schröpl]

Hi Nicole,

Es sind zwar mittlerweile 20.000 Datensätze,
aber dennoch sollte das nicht so langsam sein.

welche Indexstrukturen liegen auf Deinen Tabellenspalten?
Wie stark projezieren diese?

Das kann leicht mehrere Zehnerpotenzen an Geschwindigkeit ausmachen ...

Viele Grüße
      Michael

[Harry]

Holladiewaldfee,

Wie stark projezieren diese?

magst Du mal schnell erklären, was das heißt?
Fände ich nämlich auch interessant :-)))

(Darf natürlich auch ein netter Link sein)

Ciao,

Harry

[Michael Schröpl]

Hi Harry,

Wie stark projezieren diese?
magst Du mal schnell erklären, was das heißt?
Fände ich nämlich auch interessant :-)))

mit 'projezieren' meine ich das Verhältnis zwischen

• der Anzahl Einträge der Tabelle und
• der Anzahl Einträge pro Schlüsselwert.

Ein Primary Key projeziert optimal (n:1); ein Key kann aber auch beliebig viel schlechter projezieren.
Wäre beispielsweise das Forums-Archiv eine relationale Tabelle, dann würde etwa die Spalte 'topic' einige hunderttausend Beiträge in nur ca. 30 Gruppen unterteilen, also immer noch viele tausend Treffer pro Schlüsselwert liefern, die dann alle noch genauer untersucht werden müßten ... in diesem Falle würde sich ein Index über diese Spalte nicht lohnen.

Je mehr Treffer ein Schlüsselwert liefert, desto teurer ist es, den zusätzlichen Overhead des Zugriffs auf einen Indexbaum zu bezahlen, statt einfach linear über die ganze Tabelle zu laufen ("full table scan").
Es kann natürlich immer noch großartig sein - denn der Overhead ist konstanter Natur (ein Faktor zwischen 5 und 10 ist eine gute Näherung), während der Gewinn durch einen Indexzugriff logarithmischer Natur ist: Eine Tabelle mit 1000 Einträgen läßt sich durch einen binären Index-Baum mit Höhe 10 abbilden - bei der Suche nach einem bestimmten Wert wären hier also nicht im Erwartungswert 500 Vergleiche erforderlich (die Anzahl der Vergleiche ist gleichverteilt zwischen 1 und 999), sondern nur ca. 50-100 (die Nutzinformation des Baums steckt in den Blättern).

Das ist immerhin fünf- bis zehnmal so schnell wie ohne Index. Und deshalb lohnt es sich, seine Tabellen- und Indexstruktur den tatsächlich erforderlichen Queries sehr exakt anzupassen.

Viele Grüße
      Michael

[Harry]

Holladiewaldfee,

mit 'projezieren' meine ich das Verhältnis zwischen

• der Anzahl Einträge der Tabelle und
• der Anzahl Einträge pro Schlüsselwert.

Danke, Michael :-)
Jetzt bin ich schon etwas schlauer als vorher, hab aber gleichzeitig festgestellt, daß ich wohl doch nicht soooo viel Ahnung von Datenbanken habe, wie ich mal dachte *g*

Kennst Du ein gutes Buch, daß sich mit dem Thema beschäftig oder vielleicht gar ein gutes Tutorial zum Thema "so verteile ich meine Datenbank-Indizes richtig"?

Ciao & Danke,

Harry
 (nur echt mit großem "H" und dem Smiley - alles andere sind Fälschungen!)

[Michael Schröpl]

Hi Harry,

Kennst Du ein gutes Buch, daß sich mit dem Thema beschäftig oder vielleicht gar ein gutes Tutorial zum Thema "so verteile ich meine Datenbank-Indizes richtig"?

es geht nicht darum, Indizes zu 'verteilen'.

Es geht darum, zu verstehen, über welche Zugriffspfade das RDBMS die Daten einer Tabelle für ein konkretes, einzelnes SQL-Statement adressieren kann.
Was Du also brauchst, das ist zunächst einmal die Notwendigkeit, für bestimmte (!) Zugriffe eine besonders hohe Lese-Performance zu erreichen. Bedenke, daß die Einrichtung eines zusätzlichen Indexbaums nicht nur zusätzlichen Speicherplatz kostet, sondern vor allem auch viele andere Zugriffe, nämlich das Einfügen, Löschen und Ändern von Datensätzen, langsamer macht, weil der zusätzliche Indexbaum in vielen Fällen mit angepaßt werden muß! Andererseits kann ein Index genau dieselben Operationen auch erheblich beschleunigen, weil sie alle implizit ebenfalls Queries sind ...
Indizes müssen "ihr Geld wert sein", und zwar in der Summe über sämtliche SQL-Statements gegen diese Datenbank.

Wenn Du ein konkretes Statement tunen willst, dann schau Dir die Ausgabe von EXPLAIN auf dieses Statement an - üblicherweise zeigt Dir das RDBMS hier, wie es vorgehen würde und was das ungefähr kosten könnte. Wie man dann die passenden Indexe findet, das ist zum großen Teil Übung.
Das Problem ist vor allem, daß man beim Tuning gezwungen wird, die Vorgänge einer deskriptiven Programmiersprache eben doch algorithmisch nachzuvollziehen, um die Schwachstellen bei der automatischen Code-Generierung durch das RDBMS zu finden und zu beheben.

Lesetips:

• Beschreibung von CREATE INDEX im Handbuch Deines RDBMS
• "Performance Tuning Guide" Deines RDBMS
• Theoretischer Hintergrund: "Balancierte B*-Bäume" (als Suchbegriff)

Viele Grüße
      Michael