WHERE aus einer Tabelle

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

Ich muss für mehr als 12’000 Nummern eine zusätzliche, eindeutige Ext_Referenz ziehen. Diese zwei Values befinden sich zwar in der gleichen View/Tabelle, aber mit meinem SELECT kann ich nur max. 2000 Nummern abfragen und eine Abfrage dauert rund 1 Stunde.

SELECT Ext_Ref, Nummer
FROM Extract_BBCS
WHERE Nummer in (
11111111,
11111112,
…
);

Daher habe ich nun gedacht, alle Nummern in eine temp. Tabelle (mig_temp zu laden und anschliessend mit einem SELECT von der neuen Tabelle die WHERE Funktion definieren

SELECT Ext_Ref, Nummer
FROM Extract_BBCS
WHERE Nummer in (mig_temp)

Funktioniert so was überhaupt? Wenn nicht, kann mir jemand die Lösung sagen?

#2

Hi,

wenn die Abfrage über 12.000 Datensätze 1h dauert, stimmen die Indizes nicht, sowas sollte in deutlich unter 1s laufen. Leg für deine Abfrage mal einen Index auf Nummer.

Und dann kannst du auch mit Unterabfragen arbeiten

SELECT Ext\_Ref, Nummer
FROM Extract\_BBCS
WHERE Nummer in
(
 SELECT Nummer From...
)

Probier mal und dann schauen wir weiter. Wäre gut, wenn du mal deine Tabelle im pre-Tag hinschreiben würdest mit drei Beispielzeilen, dann kann man dir viel besser helfen.
Und natürlich wäre es schön zu wissen, welche Datenbank das ist.

12.000 Datensätze sind nichts!

Günther

#3

Tach,
die Lösung mit der Unterabfrage sollte gehen.

Du könntest aber auch einfach deine Suchwerte in eine temporäre Tabelle legen, wie es deine Idee war, und sie dann mit einem INNER JOIN abfragen:

SELECT mytable.wertspalte
FROM mytable
INNER JOIN temptable ON temptable.wertspalte = mytable.wertspalte

Wenn du zudem noch einen Index auf beide „wertspalte“ legst, solltest du sehr kurze Antwortzeiten erreichen können.

Gruss,
SomeOne

#4

Hallo Günther

Perfekt, danke für deine Antwort. Hat einwandfrei geklappt. Noch zur Dauer des Statement: das ist eine View und daher dauert es so lange.
LG, Marcel

#5

Moin, Marcel,

Noch zur Dauer des Statement: das ist eine View und daher
dauert es so lange.

eine View braucht kein bisschen länger als der Select auf die Tabelle. Ein passender Index wirkt wahre Wunder.

Gruß Ralf

1 Like
#6

anders beschrieben
ohne index wir eine vollsuche nötig ,

nachzulesen hier
https://dev.mysql.com/doc/refman/5.5/en/mysql-indexe…

jeder sinvolle index macht es schneller .

#7

und noch wichtig fürs detail
https://dev.mysql.com/doc/refman/5.5/en/how-to-avoid…

#8

Moin,

mich musst Du nicht überzeugen. Außerdem riskierst Du mit der Antwort an mich, dass Marcel sie erst gar nicht liest.

Gruß Ralf

#9

Hi!

eine View braucht kein bisschen länger als der Select auf die
Tabelle. Ein passender Index wirkt wahre Wunder.

Leider hat der UP noch immer kein DB-System rausgerückt (oder hab ich was überlesen?), jedenfalls würde einerseits eine Materialized View (Oracle-Sprech) das Ganze noch mal schneller machen, andrerseits behauptet er, dass es um 12000 Datensätze geht.

Was ich mich frage: Umfassen diese 12.000 Rows die gesamte Tabelle? (Kommt auch irgendwie nicht raus) Oder ist das nur ein kleines Rowset? (Und die Tabelle hat 120.000.000 Datensätze)

Ein Index sollte natürlich hier helfen (wohlgemerkt: „sollte“), könnte aber genauso nach hinten losgehen; ob nun ein Full-Index- oder ein Full-Table-Scan gemacht wird, ist meist auch schon egal, aber wenn es dann schon existierenden Indizes gibt, ist die Frage, wie sich ein neuer Index auf das bestehende System auswirkt (was sich natürlich mit Optimizer Hints optimieren läßt).

Was auch noch sein könnte: Das DBMS ist komplett verkonfiguriert, zuwenig Speicher zugewiesen, Datenfiles zu klein mit zu vielen „verstreuten“ Extents, etc.

Und dann wäre da noch der Zustand der Festplatte - eine langsame DB hat mir schon des öfteren eine sterbende HD offenbart.

Kurz und gut: Ein Index ist gut und schön, die Gefahr aber, ohne entsprechende DB-Kenntnisse sehr hoch, dass nach einer gewissen Zeit 80-90% unnütze Indizies „herumliegen“, die selber die DB lahmlegen können.

Grüße,
Tomh

PS: Index auf die Table legen (ich hoffe, es war auch so gemeint :wink:, auf eine View wirst Du Dich schwer tun.

#10

Dieses Feld ist ein Pflichtfeld.