Ladezeit zu lang?

[struppi]

Schon klar, das heißt du hast keinen Index und keiner wird verwendet. Da man jetzt zumindest die Abfrage und die Struktur kennt, können wir dir wenigstens sagen worauf du einen Index setzen kannst. Was aber nicht die unpassende Struktur verbessert.

Auf jeden Fall einen Index braucht JM, für die anderen beiden Feldern musst du es mal probieren. Das Problem ist, dass ein Index Platz braucht und lange varchar Felder diesen enorm erhöhen und damit die Geschwindigkeit des Index verringern.

EXPLAIN SELECT'Bezeichnung,Gueltig_ab,Gueltig_bis,Abrechnu ngswert_kwh,Abgegrenzter_wert,Bilanzkreis,Haendler ,Firma,JM'
FROM Zaehlpunkte_slp
WHERE'JM' ='201001'
AND'Bilanzkreis' ='GASPOOLH00420003'
AND'Bezeichnung' ='DE7000731745449000107440000000000'

Ist das wirklich die abfrage? das ist ziemlich falsch.

 

[Flemli200]

Ja, also die Abfrage... bis auf das was zwischen Select und From steht... das ist anders... ansonsten... ja...
wieso... was ist denn falsch?
Also... die Formatierung stimmt nicht ganz ;) aber ansonsten?

 

[struppi]

Den Index hast du gesetzt und dann noch mal Explain benutzt?

Deine Abfrage:

EXPLAIN SELECT'Bezeichnung,Gueltig_ab,Gueltig_bis,Abrechnu ngswert_kwh,Abgegrenzter_wert,Bilanzkreis,Haendler ,Firma,JM'
FROM Zaehlpunkte_slp
WHERE'JM' ='201001'
AND'Bilanzkreis' ='GASPOOLH00420003'
AND'Bezeichnung' ='DE7000731745449000107440000000000'

Die Anführungszeichen für Felder sind allgemein falsch, damusst du backticks nehmen und dass du alle Felder in einen String eingebaut hast kann eigentlich gar nicht funktionieren.

 

[Flemli200]

meine Problematik ist ja, das ich nich weiß, wie ich einen index setze... hab mir schon viele sachen dazu durchgelesen...
versteh aber nicht, wie ich das nachträglich mache...

 

[struppi]

meine Problematik ist ja, das ich nich weiß, wie ich einen index setze... hab mir schon viele sachen dazu durchgelesen...
versteh aber nicht, wie ich das nachträglich mache...

am einfachsten in phpmyadmin, aber was hast du dir durchgelesen wo das nicht steht?

 

[Flemli200]

An sich steht das da schon... ich versteh das blos nicht...
und wenn ich versuche - so wie ich das verstehe - CREATE INDEX JM oder ähnliches auszuführen, dann gibt er mir eine falschmeldung aus.

-> ich werde mich warscheinlich später über diese antwort totlachen und ich wette du musst auch schmunzeln ;) bei dieser antwort ^^

Aber noch verstehe ich das nicht so ganz ^^

Und wenn ich das getan hab also den Index gesetzt... wie les ich das dann später aus... ^^

 

[struppi]

Du kannst doch in phpmyadmin direkt - also ohne sql - den Index setzen.

EDIT: Du musst nichts auslesen, ein Index ist nur für mysql interessant. Ob er benutzt wird sagt dir dann Explain

 

[Flemli200]

Okay... hab den index jetzt gesetzt.
Hier die erneute EXPLAIN abfrage:

EXPLAIN SELECT 'Bezeichnung','Gueltig_ab','Gueltig_bis','Abrechnungswert_kwh','Abgegrenzter_wert','Bilanzkreis','Haendler','Firma','JM'
FROM Zaehlpunkte_slp
WHERE'JM' = '201001'
AND'Bilanzkreis' = 'GASPOOLH00420003'
AND'Bezeichnung' = 'DE7000731745449000107440000000000'

Hier die Ausgabe:

id select_type table type possible_keys key key_len ref rows Extra

1	SIMPLE	NULL	NULL	NULL	NULL	NULL	NULL	NULL	Impossible WHERE

Hat sich von der ausgabe her zu vorher nichts verändert...

 

[struppi]

Die Abfrage ist immer noch falsch. Der Index ist auf das Feld JM

 

[Flemli200]

Ich glaub jetzt ist die Abfrage richtig ;)
(Dieses Textfeld zerschießt das ganze in sachen leerzeichen ^^)

EXPLAIN SELECT `Bezeichnung`,`Gueltig_ab`,`Gueltig_bis`,`Abrechnungswert_kwh`,`Abgegrenzter_wert`,`Bilanzkreis`,`Haendler`,`Firma`,`JM`
FROM Zaehlpunkte_slp
WHERE `JM`="201001" AND `Bilanzkreis`="GASPOOLH00420003"
AND `Bezeichnung`="DE7000731745449000107440000000000"

Hier die Ausgabe:

1

SIMPLE

Zaehlpunkte_slp

ref

JM

JM

4

const

14974

Using where

 

[struppi]

Das ist gut. In phpmyadmin wird dir auch angezeigt wie lange die Abfrage dauert, hast du schon einen Unterschied gemerkt?

 

[Flemli200]

An sich schon... nur weiß ich nicht ob der sich sooo stark auswirkt...
anstatt 0.0014 braucht er nur noch 0.0004 um

SELECT*
FROM`zaehlpunkte_slp`
LIMIT 0 , 30

abzurufen.
Wie sich das später bei 120000 datensätzen auswirkt muss ich gucken.
Mach denn nochmal einen Datenimport und schau ob das wieder stunden ;) dauert.

Eine frage noch: würde sich die geschwindigkeit noch mehr verbessern wenn ich als bsp. den bilanzkreis auch als indes setze?

 

[struppi]

Bei der Abfrage wird auch kein Index benutzt. Du musst natürlich die Abfrage verwenden, über die wir ursprünglich sprachen.

Eine frage noch: würde sich die geschwindigkeit noch mehr verbessern wenn ich als bsp. den bilanzkreis auch als indes setze?

Das ist das was ich vorhin sagte. Das kann sein, es kann aber auch nicht sein. Da ein Index auf ein varchar(100) Feld sehr gross werden kann. Das musst du einfach mal ausprobieren, phpmyadmin kann dir dabei helfen. Es gibt da auch ein Kästchen messen [] bei der abfrage.

 

[sysop]

Nachdem du deine Tabelle auf gerade gebogen hast:

Lies doch bitte nochmal meinen Link constraint-primary-key zum Thema.
Bei einem gezielten Einsatz von Indizes (unique, da ja keine doppelten Einträge vorhanden sein sollen) und dem Schlüsselwort Ignore kann eine Prüfung der eingespielten Daten komplett entfallen.
Du spielst also nur Datein ein, was bei der Anzahl in einem Schwung gehen sollte.

Du indizierst die Zeilen, die nie doppelte Einträge enthalten sollen mit unique und setzt in deinen Insert Queries das Schlüsselwort IGNORE, dann bricht bei einem doppelten Eintrag der Einleseprozess nicht mit einem Fehler ab sondern ignoriert den betreffenden Datensatz einfach und arbeitet mit dem nächsten Datensatz weiter.

 

[zorndyuke]

Sry... hab mich komisch ausgedrückt ;)

Also bei der Abfrage (EXPLAIN tabellenname) von der großen tabelle, kam folgendes raus

Eingabe: EXPLAIN zaehlpunkte_slp

Ausgabe:

id	int(255)	NO	PRI	NULL	auto_increment
Bezeichnung	varchar(100)	NO		NULL
Gueltig_ab	varchar(100)	NO		NULL
Gueltig_bis	varchar(100)	NO		NULL
Abrechnungswert_kwh	double(12,6)	YES		NULL
Abgegrenzter_wert	double(12,6)	YES		NULL
Bilanzkreis	varchar(100)	NO		NULL
Haendler	varchar(100)	NO		NULL
Firma	varchar(100)	NO		NULL
JM	int(255)	NO		NULL

was heißt das jetzt?
Hab wie gesagt wenig erfahrung mit sql ^^

Mal eine Frage zu dieser Tabelle:

Ist der Value Wert hinter dem DatenTyp INT nicht die Anzahl an Stellen wie groß der Int sein darf?
Also INT ( 11 ) gleich 99999999999 als Maximale Zahl ( Was bei Auto_Inc Werten rein Theoretisch erst nach Jahrhunderten passieren dürfte ).
Wenn Ja, wäre "int( 255 )" ja viel zu viel bzw. wenn ich mich Irre bei >16.000 Datensätzen 255 zu wenig.

Wenn meine Annahmen stimmen, könnte dies doch zu vergrößerten Ladezeiten dauern nicht wahr?

 

[struppi]

Diese Zahl gibt bei int Werten nur die "Anzeigenbreite" an.
MySQL :: MySQL 5.1 Referenzhandbuch :: 11.2 Numerische Datentypen

Eine andere Erweiterung wird von MySQL zur optionalen Spezifizierung der Anzeigebreite eines Integer-Werts unterstützt. Die Angabe erfolgt auf das Schlüsselwort für den Datentyp folgend in Klammern (z. B. INT(4)). Diese optionale Angabe der Anzeigebreite wird verwendet, um die Anzeige von Werten, die eine geringere als die für die Spalte festgelegte Breite aufweisen, nach links mit Leerzeichen aufzufüllen.

Die Anzeigebreite schränkt weder die in einer Spalte speicherbaren Wertebereiche noch die Anzahl der Stellen ein, die für Werte angezeigt werden, deren Breite die festgelegte Spaltenbreite überschreitet.

Zeigt aber trotzdem, dass hier jemand nicht nachgedacht hat. Wozu sollte man eine maximal 11 Stellige Zahl in einer Breite von 255 Stellen anzeigen wollen?

 

[Flemli200]

Du indizierst die Zeilen, die nie doppelte Einträge enthalten sollen mit unique und setzt in deinen Insert Queries das Schlüsselwort IGNORE, dann bricht bei einem doppelten Eintrag der Einleseprozess nicht mit einem Fehler ab sondern ignoriert den betreffenden Datensatz einfach und arbeitet mit dem nächsten Datensatz weiter.

Das ist enie super idee...
Eine frage hätte ich dazu aber noch...
Ich habe werte wie bilanzkreis als bsp. der in jedem Monat also jedem JM wieder vorkommt... funzt deine methode auch, wenn nur ALLE drei werte (die nur in der kombination noch nicht existieren dürfen) noch nicht in der kombination existieren?

Denn nach dem, wie ich mir das denke, liest er einfach hmm... der wert existiert schon in einer Datenbank... den kann ich nciht schreiben weil unique und springt dann weiter.

Wär für mich cool, weil ich keinerlei prüfung mehr hätte... Aber ob das so funzt?

 

[sysop]

Das lässt sich über zusammengesetzte Keys regeln, wo alle Arten von Kombinationen der Primärschlüssel vorkommen dürfen. Das ist etwas komplex, aber ich versuche das mal in aller Kürze zu erklären

Wir nehmen für eine Schulnotentabelle mal folgendes an.

Schüler hat eine ID-Nummer 1
Fächer sind mal nur 2, 1=Englisch, 2=Deutsch
Noten sind logisch von 1 - 5 (Österreich, da gibt es keine 6 :-) )


Eine Tabelle hat auf den Spalten Schüler Und Fachnummer einen Primary Key

[FONT=system]
[/FONT][B]Schülerid[/B]  |  [B]Fachnummer[/B]  |  Schulnote
-----------+--------------+----------------
     [COLOR=#ff0000]1[/COLOR]     |       [COLOR=#ff0000]1[/COLOR]      |        2                   (erlaubt)
     1     |       2      |        3                   (erlaubt)
     [COLOR=#ff0000]1[/COLOR]     |       [COLOR=#ff0000]1[/COLOR]      |        3                   [verboten, Kombination 1 (Schüler) und 1 (Englisch) gibt es schon in Zeile 1, Fach ist also schon benotet]

Ich weiss ja nicht, welche Kombinationen bei deinen Importdaten doppelt vorkommen, da muss ich eben raten. Daher meine Bitte nach mehr Informationen.

Primärschlüssel werden übrigens meines Wissens immer automatisch Indiziert (korriert mich, wenn ich falsch liege).
Das Schlüsselwort IGNORE verursacht dann nur keinen Fehlermeldung der Datenbank und sie bricht nicht ab sondern arbeitet einfach mit dem nächsten Datensatz weiter.

 

[struppi]

Ja, primary wird indiziert, aber soweit ich weiß ist es nicht erlaubt einen zusammengesetzen primary Schlüssel zu verwenden. Was aber in dem Fall egal ist, es muss ja kein primary key sein (sofern unique auch auf andere Indizes anwendbar ist). Das Problem dürfte aber sein, wenn du einen zusammengesetzen Index aus den von dir gewünschten Felder erstellst, wird der Index u.U. riesig, da diese Werte alles lange varchar Felder sind.

Aber diese Tabelle ist dermaßen missraten, da dürfte es egal sein. Wenn wir jetzt noch erfahren das JM der Monat sein soll, dann wird es immer dringender, das sich Flemli200 sich etwas intensiver mit Datenbanken beschäftigt. Weil wir doktorn jetzt nur an irgendwelchen Symptomen ohne die Ursachen beseitigen zu können.

 

[Flemli200]

Hi,
hab die werte in den int felder angepasst und 3 Felder (JM, Bilanzkreis und Beschreibung) als index gesetzt.
Die Tabelle braucht zwar immer noch ein wenig um die datensätze einzulesen aber ich konnte so die Abfragezeit halbieren!
Das ist suuuper!
VIELEN DANK!

@sysop: das mit den keys versteh ich nicht so ganz... und um dir mehr infos zu geben ;) ich habe einen bilanzkreis. Dieser kommt mehrmals in jedem der 12 Monate vor. JM existiert in allen Feldern und ist überall angepasst (JahrMonat also als bsp. 201001 für januar 2010). Die Beschreibung ist einmalig und kommt in jedem der 12 Monate nur einmal vor.

Wenn ich jetzt also JM, Beschreibung und Bilanzkreis als unique setz, funzt das doch nicht oder versteh ich das falsch?



Habt ihr einen Tipp für ein Tutorial, in dem ich mir das wissen zur datenbank aneignen kann?
Würd nämlich echt gerne mehr damit arbeiten, aber wie schon gesagt hab ich das wissen dazu NOCH nicht und meine abfragen und inhalte alle
zusammengestückelt.