Laden...

Datenbankoptimierung mit Indexen

Erstellt von sindibad vor 10 Jahren Letzter Beitrag vor 10 Jahren 1.909 Views
S
sindibad Themenstarter:in
110 Beiträge seit 2012
vor 10 Jahren
Datenbankoptimierung mit Indexen

verwendetes Datenbanksystem: <Oracle 11.2>
Hallo ich versuche eine Datenbank zu optimieren weil die Lesen langsam ist.
meine Datenbank besteht aus 6 Tabellen(siehe Bild)

was ich bis jetzt gemacht habe:

  • alle Spalten, die öfter in where Klausel stehen indiziert.
  • ein paar fremdschlüsseln indiziert weil sie öfter in joins verwendet werden

aber ich habe auch gelesen, dass wiederum zuviel indexen den datenbank verlangsammen

disen Artikel fande ich interessant
http://www.objectcode.de/uploads/media/Oracle-Optimierung-f%C3%BCr-Entwickler_02.pdf (Edit gfoidl 18.07.2013: wenn der Link nicht mehr geht, siehe Datenbankoptimierung mit Indexen).

das steht drin das man alle Fremdschlüsseln indizieren soll

habt ihr noch andere tips für die Optimierung vor allem die indizierung?

3.511 Beiträge seit 2005
vor 10 Jahren

Bevor du "blind" Indizes anlegst, schau dir die Ausführungspläne der langsamen Statements an.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

3.825 Beiträge seit 2006
vor 10 Jahren

aber ich habe auch gelesen, dass wiederum zuviel indexen den datenbank verlangsammen

Langsamer wird nur das Ändern, Einfügen und Löschen von Tabellenzeilen.
Das reine Lesen wird durch mehrere Indexe nicht langsamer.

Um welche Datenmengen geht es denn ?

Grüße Bernd

Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3

6.911 Beiträge seit 2009
vor 10 Jahren

Hallo sindibad,

schau dir mal SQL Indizierung und Tuning | Use The Index, Luke an.

Den oben verlinkten PDF-Artikel hab ich hier angehängt, wegen [Hinweis] Wie poste ich richtig? Punkt 6.1. analog. Du hättest dafür ruhig 2 Beiträge hintereinander erstellen können.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

S
sindibad Themenstarter:in
110 Beiträge seit 2012
vor 10 Jahren

Hallo und danke für eure Antworten

@BerndFfm: es geht um Millionen von Datensätze

@gfoidl: danke für den Link, werde ich mal in Ruhe lesen und sorry für den falschen post

V
162 Beiträge seit 2010
vor 10 Jahren

Hi,

wieviele Millionen meinst du? Es ist schon entscheident.

@BerndFfm: Viele Indexe können auch das lesen langsammer machen, wenn der Optimizer den falschen Index wählt. Es ist wie immer das maß der Dinge. Nicht zu viel und nicht zu wenig.

@sindibad:
-SQLPLUS und dort mal EXPLAIN deiner SQL Statments eingeben. Wenn eins ein Full-Tablescan macht, must du optimieren.

  • FK kosten beim einfügen, etc. Performance.
  • Trigger kosten beim einfügen, etc. Performance.

Bei Oracle 8 brachte es performance eine Index nach der häufigkeit von unterschiedlichen werten anzulegen.
z.B.:
create index on Table XXX ON BOOLEAN, NUMBER, DATETIME
(Anhand des Datentypen veranschauliche ich die Möglichkeit von unterschiedlichen einträgen.)
Zu erst die wenigst häufig wechselnden Spalten und zu letzt die am warscheinlichst häufigst unterschiedlichen Spalten.

Manchmal muss man einfach eine Index anlegen nur für eine Spalte. Nur weil das Where über 2 Spalten geht muss der Index nicht über beide gehen. Das muss man messen und Teste.

Fremdschlüssel müssen immer Indiziert werden. Bei einem FK passiert das dann Automatisch. (Bin nicht 100% sicher ob das bei Oracle auch so ist.)

Optimieren kannst du auch indem du das Tablespace für Indexe auf ein Stripeset (Raid 0) legst.

Hast du Blobs in deiner Tabelle? Wenn ja bedeutet das immer ein Read wenn du die "Select * from tabelle" machst. Wenn du Blobs hast bitte immer die Abfragen ohne "*" machen wenn man den Blob nich benötigt., da es sonst immer ein I/O Read bedeutet und somit performance.

Eine umstellungen der SQL Statmens kann auch Geschwindigkeit bringen.

Z.B. Die Ergebnissmenge zu erst klein machen und dann Groupieren.

Ach es gibt einfach zu viele möglichkeiten eine Datenbank zu Optimieren um dir die passende zu liefern. Einfach mal ein gutes Buch lesen.

LG
Björn

Das Leben ist schön!

F
115 Beiträge seit 2012
vor 10 Jahren

Huhu,

dieser Aussage

Zu erst die wenigst häufig wechselnden Spalten und zu letzt die am warscheinlichst häufigst unterschiedlichen Spalten.

muss ich leider auf das heftigste Wiedersprechen! Ein Index ist dann besonders wirksam, wenn das Filterkriterium möglichst weit vorne im Index steht. Bei mehreren Kirterien sollte das Kriterium mit der höchsten Frequenz vorne stehen. Dadurch wird beim Zugriff die Ergebnismenge schon durch den Filter auf das erste Feld erheblich eingschränkt!

bitte immer die Abfragen ohne "*" machen

kann ich hingegen voll und ganz unterstüzen. Je weniger man Selektiert desto besser. Viele DB-Systeme beherrschen auch sog. Index-only Zugriffe, d.h., dass falls ein Index alle benötigten Informationen enthält, gar kein Zugriff auf die Tabelle passiert!

Auch das hier

Wenn eins ein Full-Tablescan macht, must du optimieren.

stimmt nicht immer. Wenn Du alle oder fast alle Sätze einer Tabelle lesen willst ist der Relation Scan eben der beste Zugriff, den man nicht weite optimieren kann!

Ach es gibt einfach zu viele möglichkeiten eine Datenbank zu Optimieren um dir die passende zu liefern. Einfach mal ein gutes Buch lesen.

Ist ein guter Tipp! Einfach nur Indexe über Tabellen zu streuen bringt in der Regel wenig. Wichtig sind vor allem ein gutes DB-Design und vernünftige SQLs. Grundsätzlich kann man annehmen, dass mehr als drei Indexe auf einer Tabelle verdächtig sind. Das heist natürlich nicht, dass es auch Fälle gibt, wo es sinvoll sein kann 30 Indexe auf einer Tabelle zu haben. Allerdings kenne ich kein Beispiel 😉!

Gruß
f_igy

V
162 Beiträge seit 2010
vor 10 Jahren

Huhu,

dieser Aussage

Zu erst die wenigst häufig wechselnden Spalten und zu letzt die am warscheinlichst häufigst unterschiedlichen Spalten.

muss ich leider auf das heftigste Wiedersprechen! Ein Index ist dann besonders wirksam, wenn das Filterkriterium möglichst weit vorne im Index steht. Bei mehreren Kirterien sollte das Kriterium mit der höchsten Frequenz vorne stehen. Dadurch wird beim Zugriff die Ergebnismenge schon durch den Filter auf das erste Feld erheblich eingschränkt!

Hi du hast recht es war genau anders rum. Sorry war gestern Spät.

...

Auch das hier

Wenn eins ein Full-Tablescan macht, must du optimieren.
stimmt nicht immer. Wenn Du alle oder fast alle Sätze einer Tabelle lesen willst ist der Relation Scan eben der beste Zugriff, den man nicht weite optimieren kann!
...

Ok man muss eben immer wissen was man tut. Deshalb ja auch meine allgemeines Fazit am Ende, dass es viele Wege gibt und kein alleiniges Lösungsmittel, wie z.B. nur eine Index anlegen reicht.

LG
Björn

Das Leben ist schön!

F
115 Beiträge seit 2012
vor 10 Jahren

Hi Björn,

Deinem Fazit kann ich mich voll und ganz anschließen.

Schönen Tag uns sonniges Wochenende wünscht
f_igy