Alle Datensätze zählen

[Bernd]

Hallo,

ich habe in meiner MySQL Datenbank 110 Tabellen, gibt es eine Möglichkeit alle Datensätze zu zählen und mir ausgeben zu lassen? Würde mich mal interessieren wie viel Inhalt die Datenbank hat. Wenn ich ein Export mache sind es mittlerweile 12.2 MB

[Orlok]

Hallo

ich habe in meiner MySQL Datenbank 110 Tabellen, gibt es eine Möglichkeit alle Datensätze zu zählen und mir ausgeben zu lassen? Würde mich mal interessieren wie viel Inhalt die Datenbank hat.

Für eine Abschätzung der Anzahl der Datensätze sollte Folgendes reichen:

SELECT
    SUM(TABLE_ROWS)
FROM
    INFORMATION_SCHEMA.TABLES
WHERE
    TABLE_SCHEMA = 'deine Datenbank';

Je nach dem, welche Storage Engine verwendet wird (etwa bei InnoDB), ist das vielleicht nicht die exakte Anzahl der Datensätze sondern nur eine Schätzung. Wenn dir das genügt, gut. Sonst müsstest du wohl etwas umständlicher mit COUNT zählen.

EDIT: Rolf hat natürlich Recht, dass die Anzahl der Datensätze allein wenig Aussagekraft besitzt, wenn es um den Speicherverbauch deiner Datenbank geht.

SELECT
    TABLE_NAME,
    ROUND(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) AS 'Size in MB'
FROM
    INFORMATION_SCHEMA.TABLES
WHERE
    TABLE_SCHEMA = 'deine Datenbank';

Diese Abfrage gibt dir die Größe der einzelnen Tabellen. Beachte, dass DATA_LENGTH und INDEX_LENGTH in Bytes vorliegen. Das willst du wahrscheinlich umrechnen. Wenn du nur an der Größe der gesamten Datenbank interessiert bist, kannst du die Einträge wie im folgenden Beispiel aufsummieren.

SELECT
    SUM(ROUND(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2)) AS 'Size in MB'
FROM
    INFORMATION_SCHEMA.TABLES
WHERE
    TABLE_SCHEMA = 'deine Datenbank';

Viele Grüße,

Orlok

[Rolf B]

Hallo Bernd,

die Anzahl der Sätze ist nicht relevant für Speicherabschätzungen. Die Breite der Sätze spielt ja auch eine Rolle.

PhpMyAdmin sagt Dir aber alles: Sätze und Bytes: Klick in der Navigation links auf die Datenbank und dann auf den Struktur-Tab. Da gibt's eine Summenzeile am Ende.

Rolf

[Bernd]

Hallo,

oh die Ausgabe ist mir noch gar nicht aufgefallen. Sind folgende Werte viel für eine Datenbank?

1. 117,909 Einträge
2. Größe 18 MiB
3. Überhang 2 MiB

[ursus contionabundo]

oh die Ausgabe ist mir noch gar nicht aufgefallen. Sind folgende Werte viel für eine Datenbank?

1. 117,909 Einträge
2. Größe 18 MiB
3. Überhang 2 MiB

Wenn man eine Zeitreise ins Jahr 1993 und zum 386er Prozessor macht: "womöglich". Aber anno 2018 ist das selbst auf Minicomputern im Zigarettenschachtelformat (z.B. Raspis) keine "Hausnummer" mehr. Solche Daten"mengen" dümpeln anno 2018 im Cache und die Antwortzeiten sollten im einstelligen Mikrosekunden-Bereich liegen.

[MudGuard]

Hi,

oh die Ausgabe ist mir noch gar nicht aufgefallen. Sind folgende Werte viel für eine Datenbank?

1. 117,909 Einträge
2. Größe 18 MiB
3. Überhang 2 MiB

Niedlich, die kleine DB 😉

Ich hab beruflich mit einer DB zu tun, da hat die größte Tabelle ca. 2,5 Milliarden Records, dazu gibt es mehrere Tabellen mit mehreren Hundert Millionen Records, einige mit mehreren Zig Millionen. Und noch einige Hundert Kleinkramtabellen.

Speicherplatz: etwa eineinhalb Terabyte für die Daten, nochmal ein Terabyte für die Indizes.

(ok, ist nicht MySQL, sondern Oracle)

cu,
Andreas a/k/a MudGuard

[Bernd]

Hallo,

Wahnsinn 😯 Und wie machst du bei so großen Datenbanken ein Backup? Das geht ja Stunden? Oder wenn du in der Datenbank etwas suchen musst, geht bestimmt Minuten bis du eine Antwort hast?

[MudGuard]

Hi,

Wahnsinn 😯 Und wie machst du bei so großen Datenbanken ein Backup? Das geht ja Stunden?

Laufend im Betrieb. (Details müßte ich bei unseren DB-Admins erfragen)

Oder wenn du in der Datenbank etwas suchen musst, geht bestimmt Minuten bis du eine Antwort hast?

Kommt immer auf die Anfrage an - für die regelmäßigen Abfragen sind die Indizes passend gesetzt, so daß das sehr schnell geht.

cu,
Andreas a/k/a MudGuard

[Rolf B]

Hallo Bernd,

große DBMS können Backup im laufenden Betrieb. Das schreibt man auf Festplatten, und diese kann man dann generationenweise auf Tape kopieren.

Es gibt Full und Delta Backups, bei 1 TB macht man nicht unbedingt täglich ein Full-Backup. Das DBMS weiß an Hand es Log, welcher Satz wann wie geändert wurde, und man sichert dann einfach das noch ungesicherte Stück des Log. Irgendwann wird das Log zu groß, und dann ist wieder ein Full Backup fällig.

Rolf

[dedlfix]

Tach!

Wahnsinn 😯 Und wie machst du bei so großen Datenbanken ein Backup? Das geht ja Stunden?

Nein, je nach DBMS gibt es Backup-Strategien, so dass man auch im Minutenabstand backupen kann. Und das ist auch wichtig, damit nicht so viel zwischen den Backups verlorengeht. Für MySQL ist das etwas eingeschränkter, aber in dessen Enterprise-Version gibt es auch mehr Möglichkeiten. Wenn man in der kleinen Variante eine zeitnahe Sicherung braucht, gibt es immerhin noch die Replikation, mit der man live einen zweiten Datenbestand pflegen kann, auf den man im Notfall recht schnell wechseln kann. Zudem gibt es Hochverfügbarkeitslösungen, die auf Betriebssystemebene ansetzen und den Verlust im Ausfallfall klein zu halten versuchen. Was man im konkreten Fall macht, bespricht man mit seinem qualifizierten Berater.

Oder wenn du in der Datenbank etwas suchen musst, geht bestimmt Minuten bis du eine Antwort hast?

Datenbanken sind so ausgelegt, dass sie große Datenmengen nicht nur effektiv sondern auch effizient verwalten können. Wenn in großen Unternehmungen große Datenmengen zu verwalten sind, gibts da oft auch qualifiziertes Personal, dass sich darum kümmert und alle Performance-Bedingungen optimal setzt.

dedlfix.

[Rolf B]

Hallo Bernd,

Oder wenn du in der Datenbank etwas suchen musst, geht bestimmt Minuten bis du eine Antwort hast?

Wenn man eine Query mit Tablescan laufen lässt, dann schon. Bei gut gewählten Indexen, und einer gewissen Selbstbeherrschung der Entwickler bei den Abfragen, ist es kein Problem.

Der Großrechner meines Arbeitgebers hat eine "Vorgangs-Datenbank". Zu jedem Vertrag ist da jeder Kundenkontakt und jedes Dokument verlinkt. Inclusive Historie, d.h. wenn es ein Statusupdate zu einem Vorgang gibt, wird der alte Satz deaktiviert und ein neuer angelegt.

Wir haben viele Millionen Verträge. Pro Vertrag gerne mal 1000 Kontakte, Dokumente, Vorgänge. Die Table ist partioniert, sie ist gut indexiert, alle SQLs darauf werden von dem Team geprüft, das für diese DB zuständig ist. Die Zugriffszeiten liegen im kleinen Millisekundenbereich. Das ist DB2 für z/OS.

Rolf