Schnelle Bestimmung der Anzahl von Datensätzen in Tabelle

[Bernhard Geyer]

In einem einfachen Ansatz ist es möglich die Anzahl der Datensätze einer Tabelle mittels:

SQL-Code:

SELECT Count(*) FROM <TabellenName>

zu bekommen.

Jedoch dauert diese Bestimmung bei sehr großen Datenbanken u.U. auch länger. Gibt es für die Datenbanken MySQL und Oracle eine optimierte Möglichkeit über Systemtabellen (normale User-Rechte) die Anzahl schneller zu bekommen?

[Sharky]

Zitat:

Zitat von Bernhard Geyer

....Jedoch dauert diese Bestimmung bei sehr großen Datenbanken u.U. auch länger....

Hai Bernhard,

mir ist bei mySQL keine Alternative bekannt. Aber was verstehtst Du unter großen Datenbanken und "länger"?
Bei einer Tabelle mit 1.000.000 Datensätzen braucht die Abfrage bei mir (Zeos) ca. 16 ms

[Bernhard Geyer]

Bei MySQL habe ich noch keine große Datenbanken. Aber evtl. ist diese Intelligent genug bei solch einer Abfrage einfach in einer Systemtabelle nachzufragen.

Aber bei Oracle habe ich auf einem "normalen" PC mit 1 GB Speicher 3 Mio. Datensätzen Antwortzeiten von 12 Sekunden. Und das ist nicht gerade optimal ...

[mikhal]

Verwende statt dem Allquantor lieber das Feld mit dem Primary Key (wenn es ihn gibt).

Grüße
Mikhal

[Catbytes]

Hallo,

mit MS-SQL eine Tabelle mit 3.8 Mio. Datensätze in 3 Sekunden.

Würde sagen, daß ist normal...

Mit

SQL-Code:

SELECT Count(<feldname>) FROM <tabelle>;

nur 2 Sekunden...

Wobei hier <feldname> einen PK hat.

[Bernhard Geyer]

Zitat:

Zitat von mikhal

Verwende statt dem Allquantor lieber das Feld mit dem Primary Key (wenn es ihn gibt).

Keine Verbesserung

Zitat:

Zitat von mikhal

mit MS-SQL eine Tabelle mit 3.8 Mio. Datensätze in 3 Sekunden.

Bei mir dauert es auf dem gleichen Rechner mit dem gleichen Datebankinhalt beim ersten mal 8 Sekunden.
Weiter Aufrufe dauern nicht mehr so lange (0,5 Sekunden). Scheinbar wirk hier Caching.

[Catbytes]

Zitat:

Zitat von Bernhard Geyer

Bei mir dauert es auf dem gleichen Rechner mit dem gleichen Datebankinhalt beim ersten mal 8 Sekunden.
Weiter Aufrufe dauern nicht mehr so lange (0,5 Sekunden). Scheinbar wirk hier Caching.

Yep - da ist der Cache aktiv, der die Abfrage noch im Speicher hat.

Was für ein Typ ist den der PK? Autozähler? String?

[Bernhard Geyer]

Zitat:

Zitat von Catbytes

Was für ein Typ ist den der PK? Autozähler? String?

Wird noch etwas dauern. Die getestete Datenbank ist noch von alten Stand, als noch keine Primärschlüssel verwendet wurden.
Muss erst noch konvertieren...

PK-Felder sind alle Stings. Für die entsprechende Tabelle werden es dann 3 Felder mit einer Gesamtschlüssellänge von 124 Zeichen sein.

[r_kerber]

Zitat:

Zitat von Bernhard Geyer

PK-Felder sind alle Stings. Für die entsprechende Tabelle werden es dann 3 Felder mit einer Gesamtschlüssellänge von 124 Zeichen sein.

Dann ist das ja auch kein Wunder. Zusammengesetzte PK's sind langsam...

[Catbytes]

Zitat:

Zitat von Bernhard Geyer

PK-Felder sind alle Stings. Für die entsprechende Tabelle werden es dann 3 Felder mit einer Gesamtschlüssellänge von 124 Zeichen sein.

Wenn Du eine entsprechende Testumgebung hast, erzeuge einen Autowert, setze eine Index darauf und probier dann mal

SQL-Code:

SELECT Count(<feldname>) FROM <tabelle>;

Wobei Feldname das Feld mit dem Index sein sollte.

[Robert_G]

Ich bin generell der Meinung, dass ein PK IMMER numerisch und IMMER keinerlei Bezug zu den Informationen in der Tabelle haben sollte. (Also die gute alte Sequence.NextVal-Geschichte. ;) ).
Dein Problem ist nämlich, dass Ora bei einem SELECT Count(*) bzw. SELECT Count(PK) versucht einfach die Anzahl der verknüpften RowIds am Index des PKs auszugeben.
Indizes sind in Ora eigentlich "nur" nested tables, deshalb könnte er wortwörtlich die Count Methode der Index collection aufrufen (PK heißt ja eine Rowid pro Index wert ;) ).

Bei so vielen Datensätzen solltest du die Tabelle am besten auch noch partitionieren (nach Projektnmmer, Hersteller, whatever,...).
Auf die Art würden Abfragen innerhalb eines Projektes, Herstellers, whatever,... so schnell laufen als gäbe es nur diese Datensätze. :)

[Bernhard Geyer]

Zitat:

Zitat von Robert_G

Ich bin generell der Meinung, dass ein PK IMMER numerisch und IMMER keinerlei Bezug zu den Informationen in der Tabelle haben sollte. (Also die gute alte Sequence.NextVal-Geschichte. ;) ).

Umstellen geht aufgrund von 3 Gründen nicht:
1, große Installierte Basis
2, PK-Schlüssel sind reale Eindeutige Nummern (z.B. Materialnummern mit Versionen bzw. Mandantennummern)
3, Installierte Daten mittels "Differnz-Update" aktualisiert werden müssen, auch wenn in der Ursprungsdatenbank evtl. Primärschlüsseleinträge zwischenzeitlich gelöscht wurden.

Zitat:

Zitat von Robert_G

Dein Problem ist nämlich, dass Ora bei einem SELECT Count(*) bzw. SELECT Count(PK) versucht einfach die Anzahl der verknüpften RowIds am Index des PKs auszugeben.

Für M$ SQL-Server wurde diese Info (Anzahl Datensätze in Tabelle) noch in einer Systemtabelle gehalten. Für Oracle gibt es scheinbar sowas nur (aktuell) wenn eine spezieller Statistikdurchlauf gelaufen ist.

Zitat:

Zitat von Robert_G

Bei so vielen Datensätzen solltest du die Tabelle am besten auch noch partitionieren (nach Projektnmmer, Hersteller, whatever,...).
Auf die Art würden Abfragen innerhalb eines Projektes, Herstellers, whatever,... so schnell laufen als gäbe es nur diese Datensätze. :)

Das wird hoffentlich von den Oracle-Admins auch durchgeführt. Selbst kann ich das in der Anwendung nicht vorsehen, da ich ja nicht weiß wie "schmal" oder "breit" die Daten ankommen und welche Partitionierung optimal wäre.

[mschaefer]

Moin, Spätmoin,

tja also hier muß ich Robert mal deutlich zustimmen. Der Primärindex sollte nichts mit den Daten zu tun haben, auch wenn die Materialnummern eindeutig sind. Hintergrund ist die wesentlich schnellere Einsortierung und vor allem indexierte-Suche. Und genau hier liegt Dein Problem! Bei einem Zähler kann das DBMS mit Suchstrategien (z.B: Bisektionsverfahren/Newtonverfahren, usw...) auf die Datensätze zugreifen. Zudem hat das DBMS nur den Integer-Ausdruck und nicht den Stringausdruck auszuwerten. Was definitiv schneller ist.

FAZIT: Besser ein eindeutiges Integerfeld als Prmärindex zusätzlich, als ein Stringindex.
Das ist sicherlich auch unabhängig vom DBMS.

Grüße // Martin

[Bernhard Geyer]

Zitat:

Zitat von mschaefer

tja also hier muß ich Robert mal deutlich zustimmen. Der Primärindex sollte nichts mit den Daten zu tun haben, auch wenn die Materialnummern eindeutig sind. Hintergrund ist die wesentlich schnellere Einsortierung und vor allem indexierte-Suche. Und genau hier liegt Dein Problem! Bei einem Zähler kann das DBMS mit Suchstrategien (z.B: Bisektionsverfahren/Newtonverfahren, usw...) auf die Datensätze zugreifen. Zudem hat das DBMS nur den Integer-Ausdruck und nicht den Stringausdruck auszuwerten. Was definitiv schneller ist.

FAZIT: Besser ein eindeutiges Integerfeld als Prmärindex zusätzlich, als ein Stringindex.
Das ist sicherlich auch unabhängig vom DBMS.

Das mag schon stimmen das die DBMS mit Integerwerten schneller zurecht kommen. Aber das Programm wird definitiv umgestellt, da es schon ziemlich groß ist (1 Mio. Quellzeilen mit Fremkomponenten) als auch schon so weit optimiert ist, das alle anderen Aktionen so weit SQL-Technisch (Primärschlüssel z.B. als Clustered Index, zusätzliche Indexe, SQL-Queries, ...) optimiert sind das auch bei 4 Mio. Datensätze immer akzeptable Antwortzeiten vorhanden sind.

Ich versteh jedoch nicht das für dieses simple Bestimmung der Anzahl der Datensätze es relevant sein soll welchen Datentyp der Primärschlüssel hat. Bei MS-SQL Server kann ich mittels

SQL-Code:

SELECT Max(idx.rows) FROM dbo.sysindexes as idx inner join dbo.sysobjects as obj on idx.id = obj.id
WHERE ( obj.name = 'Table1')

praktisch ohne Wartezeit die Anzahl der Records einer Tabelle bestimmen. Und dies sollte auch bei Oracle und MySQL möglich sein.

Meine Testdatenbank konnte ich noch nicht aktualisieren, da beim Import heute auf dem Testrechner die Festplatte vollgelaufen ist.