Where-Klausel - problem bei Laufzeit

[ny_unity]

Halllo Leute,

ich habe im Moment ein Problem, bei dem mir weitere Lösungansätze fehlen...

Folgende Abfrage:

Select * from Table

Laufzeit: 10s, 10.000 Rows

Select * from Table where Personalnr = 1

Laufzeit: 0,5s, 3 Rows

Select * from Table where Kundennr = 100000

Laufzeit: 10s, 12 Rows
Personalnr und Kundennr sind beides INT-Typen. Wieso werden für 12 Rows bei der where Klausel mit Kundennr genau in etwa die gleich Laufzeit wie für die gesamte Abfrage benötigt?


Was kann ich hier versuchen um das zu optimieren?

Dank und Gruß

Erik

 

[akretschmer]

Personalnr und Kundennr sind beides INT-Typen. Wieso werden für 12 Rows bei der where Klausel mit Kundennr genau in etwa die gleich Laufzeit wie für die gesamte Abfrage benötigt?


Was kann ich hier versuchen um das zu optimieren?

Dank und Gruß

Erik

Mal Index-Scan mal keiner? Was sagt Explain?

 

[ny_unity]

kannst du mal genauer werden? Kann damit nichts anfangen :-(

 

[akretschmer]

kannst du mal genauer werden? Kann damit nichts anfangen :-(

test=# create table ny as select * from generate_series(1,1000000) s(s);
SELECT 1000000
test=*# explain analyse select * from ny where s = 4711;
  QUERY PLAN
-----------------------------------------------------------------------------------------------------
Seq Scan on ny  (cost=0.00..17700.00 rows=5310 width=4) (actual time=0.264..118.267 rows=1 loops=1)
  Filter: (s = 4711)
  Rows Removed by Filter: 999999
Total runtime: 118.428 ms
(4 rows)

test=*# create index idx_ny on ny (s);
CREATE INDEX
test=*# explain analyse select * from ny where s = 4711;
  QUERY PLAN
-------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on ny  (cost=95.17..4793.05 rows=5000 width=4) (actual time=0.048..0.048 rows=1 loops=1)
  Recheck Cond: (s = 4711)
  ->  Bitmap Index Scan on idx_ny  (cost=0.00..93.92 rows=5000 width=0) (actual time=0.032..0.032 rows=1 loops=1)
  Index Cond: (s = 4711)
Total runtime: 0.054 ms
(5 rows)

Mal Index und mal ohne. Mal 0.054 ms, mal 118.428 ms. Siehst Du jetzt den Unterschied?

 

[akretschmer]

Mal Index und mal ohne. Mal 0.054 ms, mal 118.428 ms. Siehst Du jetzt den Unterschied?

Die Laufzeit einer Abfrage hat nur bedingt etwas mit der Anzahl der Rows im Resultat zu tun. Viel wichtiger ist die Suchstrategie, die eingesetzt wird.

 

[ukulele]

Kurz: Deine Tabelle hat einen Index auf die Spalte Personalnr, nicht aber auf die Spalte Kundenr. Der wäre recht simpel zu erstellen, du solltest dir aber mindestens den Wiki Eintrag dazu anschauen. Hier ist es auch kurz und sinnvoll erklärt: http://stackoverflow.com/questions/2955459/what-is-an-index-in-sql-server

 

[ny_unity]

hallo Leute,

danke für Eure Antworten, aber ihr konntet nicht draúfkommen, denn die 3 Beispiel Selects waren nicht annähernd am eigentlichen Select. Ich versuchs mal zu erklären:

Ich habe ein Select, das wie folgt aufgebaut ist:
Select Kundennr, Personalnr from (Select * from Table1) t1 left join (Select * from Table2) t2 .... t20
wenn ich an das Select Personalnr hänge, gehts zügig, bei der Kundennr hingegen nicht, da die Kundennr erst im t4 selektiert wurde, wurden von t1-t3 trotzdem alles selektriert. Das kostete natürlich Zeit.

Da ich aber jetzt in t1 Kundennummer und Personalnr unterbekommen habe, läuft alles, bei jedem where bin ich unter 1s.

Die Tabellen kommen von einer Firebird-Datenbank aus einem Programm, wo ich nix ändern kann, muss es so nehmen wie es ist

Danke vielmals für eure Hilfe, denn ich bin einfach mal die "Suchstrategie" durchgegangen und da ist es mir aufgefallen...

Erik

 

[ukulele]

Dann poste doch demnächst mal unter "Andere Datenbankserver", dann gebe ich mir auch gleich weniger Mühe...

 

[ny_unity]

Da bekomm ich nie antworten :-(
Die Hilfe die ich hier bekomme kann teilweise von MSSQL auf Firebird umschreiben.

So schlimm? :-(

 

[ukulele]

Ich antworte in beiden Foren. In diesem Fall war deine Problembeschreibung aber offensichtlich Käse.

 

[ny_unity]

Ja das stimmt, ist mir aber erst nach der Antwort von akretschmer bewusst geworden, als er das Statement brachte und drunter meinte zwecks suchoption.

Ich gelobe Besserung