Insert und Indizes

[naheliegend]

Hi,

könnte mir einer bitte auf einer tieferen Ebene erklären, warum mein SQL-Insert von einer row in eine Tabelle mit vielen Indizes sehr träge ist?

Also ich kann mir oberflächlich vorstellen warum, aber mich würde das gerne auf der tieferen Ebene verstehen. Hat es etwas mit der Heap-Struktur einer Datenbank zutun?

Und kann man ungefähr sagen, um wie viel Sekunden ein Index das Ganze verschleppt?

Viele Grüße und Danke!

[__deets__]

Ja, Indizes zu erzeugen kostet Zeit. Nein, man kann das vorher nicht bestimmen, weil es von viel zu vielen Faktoren abhängt.

[__blackjack__]

@naheliegend: Die relevanten Teile des neuen Datensatzes müssen halt nicht nur in die Tabelle eingetragen werden, sondern auch in alle Indexe. Das sollte aber eher nicht im Bereich von *Sekunden* liegen. Ausser das DBMS speichert auf Floppydisks.

[naheliegend]

Und die Indizes sind Objekte, die wie mit der eigentlichen Tabelle verknüpft sind?

Wie hoch ist die Laufzeit für das Einfügen in das Indexobjekt?

Normale Datenbanken sind doch als B-Baum aufgebaut oder? Und da hat doch das Einfügen O(log(n)) oder?

[__deets__]

Das kann man so überhaupt nicht beantworten. Dazu musst du dich auf ein konkretes Produkt einschiessen, und das en Detail studieren. Und dann gilt das für genau das. Verallgemeinern kann man da nicht viel. Denn neben den groben Details wie du sie selbst nennst gibt es himmelweite Unterschiede in zb Speichernutzung, Anordnung der Daten etc.

[sparrow]

Kann es sein, dass du viele Inserts auf einmal machen möchtest?

[naheliegend]

Kann es sein, dass du viele Inserts auf einmal machen möchtest?

Unter Umständen ja, aber selbst einer ist schon träge

[__blackjack__]

@naheliegend: Was sind denn ”normale Datenbanken” und was heisst ein allgemeines „sind als B-Trees aufgebaut“? Ein B-Tree ist ja nur *eine* von vielen möglichen Datenstrukturen. Was konkret für einen Index im Hintergrund verwendet wird wenn man nur die Standard-SQL-DDL verwendet, also nichts DBMS-spezifisches angibt, hängt vom verwendeten DBMS ab und kann natürlich davon abhängen ob es sich um eine „nullable“-Spalte handelt oder nicht und ob die Werte „unique“ sein müssen oder nicht, und welche(n) Typ(en) die indexierten Spalten haben, ob es ein partieller Index ist, und so weiter.

Und wenn man dann zu konkreten DBMS-Produkten kommt, kann man oft ziemlich viel an Indexen herum schrauben. Welche Datenstruktur verwendet werden soll und oft auch noch feinere Einstellungen dazu. Also nicht nur das beispielsweise ein B-Tree verwendet werden soll, sondern auch wie die Blattgrösse ist und ab welchem Füllstand Blätter geteilt werden sollen und/oder unter welchem Füllstand Blätter wieder zusammengefasst werden sollen und ähnliches.

Datenbankspezifisch gibt es eventuell auch Anweisungen um Indexe ”aufzuräumen”. PostgreSQL kennt beispielsweise ein REINDEX. Wobei das so ähnlich ist wie beim optimieren von Code: man sollte erst messen wo die Zeit bleibt bevor man teure Operationen startet die am Ende nur sehr wenig bringen.

Also grundsätzlich: Schau Dir an was Dein verwendetes DBMS an Diagnostikmöglichkeiten bietet und schau wo die meiste Zeit verbraucht wird.

Wenn *ein* Datensatz einfügen spürbar Zeit braucht, dann stimmt IMHO irgendetwas nicht. Das ist sehr ungewöhnlich.

[/me]

Unter Umständen ja, aber selbst einer ist schon träge

Von welchem DBMS reden wir hier? Selbst bei indizierten Tabellen mit x*100 Millionen Zeilen habe ich niemals auch nur annähernd eine Sekunde fürs Einfügen gebraucht.

[naheliegend]

Unter Umständen ja, aber selbst einer ist schon träge

Von welchem DBMS reden wir hier? Selbst bei indizierten Tabellen mit x*100 Millionen Zeilen habe ich niemals auch nur annähernd eine Sekunde fürs Einfügen gebraucht.

MySQL, wie viele Indizes hattest du denn?

[sparrow]

Das ist reden um den Quark.
Zeig die entsprechende Struktur der Tabelle und den Code, wie du dort etwas einfügst.
Vorher ist das Rumhumpeln im Dunkeln.

Bei einem "INSERT" von Sekunden zu reden, klingt für mich ausgesprochen ungewöhnlich.

Um das mal ins Verhältnis zu setzen. Auf meinem Laptop (casual, nichts RAM, nichts SSD) braucht ein Insert in eine MariaDB Tabelle (19 Felder, davon 10 Indices) mit mehr als 2 Millionen Datensätzen weniger als 0,02 Sekunden inklusive Commit.

[__blackjack__]

Bei MySQL könnte man sich dann Beispielsweise mal für eine problematische SQL-Anweisung den Ablaufplan anzeigen lassen und sich mit dem Performance-Schema beschäftigen und schauen wo die ganze Zeit denn so verbraucht wird.

[naheliegend]

Bei MySQL könnte man sich dann Beispielsweise mal für eine problematische SQL-Anweisung den Ablaufplan anzeigen lassen und sich mit dem Performance-Schema beschäftigen und schauen wo die ganze Zeit denn so verbraucht wird.

Das Ding ist, dass das nicht meine DB ist. Das kann wahrscheinlich nur der Server-Admin, oder?