34 lines
1.5 KiB
Markdown
34 lines
1.5 KiB
Markdown
|
+++
|
||
|
title = "Indizes statt Tabellen"
|
||
|
date = "2009-05-05T21:04:00+00:00"
|
||
|
author = "Gibheer"
|
||
|
draft = false
|
||
|
+++
|
||
|
|
||
|
Datenbanken sind dazu bestimmt Datenmengen zu verwalten, ändern,
|
||
|
löschen und einfügen. Um zumindest das einfügen und
|
||
|
aktualisieren zu vereinfachen gibt es Indizies.
|
||
|
|
||
|
Oracle hat mich heute jedoch sehr verblüfft. In einer Tabelle, auf
|
||
|
der sehr viel mit like gearbeitet wird, wurden die Abfragen immer
|
||
|
langsamer und die vorhanden Indizies konnten aufgrund des Likes nicht
|
||
|
verwendet werden. Als jedoch aber jemand einen Index über alle 4
|
||
|
Spalten gelegt hatte, wurde dieser Index allen anderen Indizes
|
||
|
vorgezogen. Aber nicht nur, dass es den Index zum suchen verwendete,
|
||
|
sondern es benutzte den Index als Tabelle. Alle Daten, die angezeigt
|
||
|
werden sollten, wurden, laut Explain, direkt aus dem Index gezogen.
|
||
|
|
||
|
Nach einer Suche in den Oracledokumenten konnte dieses Verhalten erstmal
|
||
|
nicht erklärt werden. Auf vielen Seiten wurde auch geschrieben,
|
||
|
dass like nicht index-fähig sei.
|
||
|
|
||
|
Jetzt stellt sich natürlich die Frage, warum so etwas nicht auch
|
||
|
auf einer normalen Tabelle funktioniert, denn eigentlich sollten
|
||
|
schnelle Interaktionen, also Select, Update, Insert und Delete das Ziel
|
||
|
einer Datenbank sein. Warum muss man dazu bei Oracle hier eine kopie der
|
||
|
Tabelle anlegen lassen, um genau dieses Ziel zu erreichen?
|
||
|
|
||
|
Was ich noch nicht ausprobieren konnte, ob dieser Index den Planner so
|
||
|
weit beeinflusst, dass auch Funktionsaufrufe direkt darauf gelenkt
|
||
|
werden. Ich werd mal schauen, ob ich das eingehender testen kann.
|