dabadepdu
Datenbank-Guru
- Beiträge
- 1.806
Tabelle a mit x Millionen Datensätzen, x derzeit einstellig
Tabelle b x*10 Mio. Datensätzen
Eine N:M Relation zwischen a und b
Alle mit PK und FK und zugehörigen Indizes, keine Cascade Definitionen
Bei einem massiven Löschvorgang abhängig von einem Datum in A entferne ich zunächst aus B und dann aus der NM Relation alle zugehörigen Datensätze, zuletzt aus A. Dabei verwende ich eine Temp Tabelle mit ID der zu löschenden Records.
Das alles ist sehr langsam, Tendenz unendlich. Irritierend: ausgerechnet der Löschvorgang in A (kleine Tabelle) ist sehr langsam. Explain sagt, es wird ein simple Indexscan für das Datumskriterium verwendet, ziemlich übersichtlich.
Nach einigem Hinundher habe ich „festgestellt“, dass der Zeitfresser beim Löschen der kleinen Tabelle die Prüfung der FK Constraints auf der N:M Relation ist. Der PK Index wird dabei offenbar nicht verwendet.
Also bei jedem Delete aus A wird auf N:M geschaut, ob noch Verweise da sind und dabei greift offenbar der PK auf die Schlüsselfelder nicht. Das ist allerdings eine Vermutung, da Explain darüber nichts sagt.
Proof: Erzeugt man analog zu dem bereits existierenden PK Index einzelne Indizes für die beiden PK Spalten, hat man einen enormen Geschwindigkeitszuwachs.
Hat dazu jemand einen Hinweis, entweder Richtung Explain (zu den Constraint Operationen hinter dem Delete) oder zu einem anderen Vorgehen?
Ich habe bis jetzt bewusst kein Cascade Delete drin und verspreche mir auch nichts davon, eher das Gegenteil/ ist mir unlieb. Bzw: ich könnte mir vorstellen, dass die Cascade Delete Trigger * doch schneller sind, als der jetzige Zustand. Aber nicht so schnell wie ein Massendelete auf den Einzeltabellen ohne Cascade. Habs noch nicht getestet.
Es geht erst mal nicht um Änderungen des logischen DM, Partitioning oder so, nur Analyse und Verfahrensfragen. Wahrscheinlich wird die Persistierung sowieso verschlankt. X aus Tabelle A wird dennoch eher wachsen. Das Verhalten betrifft verschiedene Versionen, die neueste ist 13.5, Standardinstallationen in VM. Neuere werde ich noch testen.
* der genaue Mechnismus dafür ist mir nicht bekannt
Tabelle b x*10 Mio. Datensätzen
Eine N:M Relation zwischen a und b
Alle mit PK und FK und zugehörigen Indizes, keine Cascade Definitionen
Bei einem massiven Löschvorgang abhängig von einem Datum in A entferne ich zunächst aus B und dann aus der NM Relation alle zugehörigen Datensätze, zuletzt aus A. Dabei verwende ich eine Temp Tabelle mit ID der zu löschenden Records.
Das alles ist sehr langsam, Tendenz unendlich. Irritierend: ausgerechnet der Löschvorgang in A (kleine Tabelle) ist sehr langsam. Explain sagt, es wird ein simple Indexscan für das Datumskriterium verwendet, ziemlich übersichtlich.
Nach einigem Hinundher habe ich „festgestellt“, dass der Zeitfresser beim Löschen der kleinen Tabelle die Prüfung der FK Constraints auf der N:M Relation ist. Der PK Index wird dabei offenbar nicht verwendet.
Also bei jedem Delete aus A wird auf N:M geschaut, ob noch Verweise da sind und dabei greift offenbar der PK auf die Schlüsselfelder nicht. Das ist allerdings eine Vermutung, da Explain darüber nichts sagt.
Proof: Erzeugt man analog zu dem bereits existierenden PK Index einzelne Indizes für die beiden PK Spalten, hat man einen enormen Geschwindigkeitszuwachs.
Hat dazu jemand einen Hinweis, entweder Richtung Explain (zu den Constraint Operationen hinter dem Delete) oder zu einem anderen Vorgehen?
Ich habe bis jetzt bewusst kein Cascade Delete drin und verspreche mir auch nichts davon, eher das Gegenteil/ ist mir unlieb. Bzw: ich könnte mir vorstellen, dass die Cascade Delete Trigger * doch schneller sind, als der jetzige Zustand. Aber nicht so schnell wie ein Massendelete auf den Einzeltabellen ohne Cascade. Habs noch nicht getestet.
Es geht erst mal nicht um Änderungen des logischen DM, Partitioning oder so, nur Analyse und Verfahrensfragen. Wahrscheinlich wird die Persistierung sowieso verschlankt. X aus Tabelle A wird dennoch eher wachsen. Das Verhalten betrifft verschiedene Versionen, die neueste ist 13.5, Standardinstallationen in VM. Neuere werde ich noch testen.
* der genaue Mechnismus dafür ist mir nicht bekannt