Warum gibt es so große Leistungsunterschiede zwischen diesen beiden Abfragen?
%Vor%gegen
%Vor%Unabhängig von den Indizes scheint es, dass sowohl to_date als auch sysdate nur "einige Datumswerte" zurückgeben.
Hinweise: Für diese Tabelle existiert ein zusammengesetzter Index, der eqpid und 2 weitere Spalten enthält. Ein Index existiert auch für mydate. Beide sind B-Baum. Es gibt ungefähr 29 Millionen Zeilen.
Warum sollte der Optimierer solch einen offensichtlich anderen (und in einem Fall grauenvollen) Plan für diese wählen?
Jonathan Lewis hat über Probleme mit sysdate in 9i geschrieben; Werfen Sie einen Blick auf den Abschnitt "sysdate", der überraschenderweise "http://books.google.co.uk/books?id=TGSd3pkMx5IC&pg=PA130&lpg=PA130&dq=jonathan+lewis+surprising+sysdate&" ; source = bl & amp; ots = 9lVdlnie9r & amp; sig = CVDQtGGghUMY6WMMcpn8oT9mYKc & amp; hl = en & amp; ei = s7fmTYfzFomXhQe5jp3MCg & amp; sa = X & amp; oi = book_result & amp; ct = Ergebnis & amp; resnum = 3 & amp; ved = 0CCkQ6AEwAg # v = eine Seite & amp; q & amp; "> hier zum Beispiel . Im Wesentlichen scheint die Arithmetik von sysdate den Optimierer zu verwirren, in diesem Fall denkt er, dass der Index auf mydate selektiver ist. Dies scheint jedoch ein recht extremes Beispiel zu sein. (Ursprünglich in dieser Richtung von einem nicht wirklich verwandten Ask Tom Beitrag gezeigt).
Ich kenne Oracle nicht, aber in Postgresql ist eine mögliche Quelle, einen Index zu ignorieren, nicht übereinstimmende Typen. Vielleicht macht es die direkte - 5 Oracle, dass die rhs numerisch ist. Kannst du bis zum heutigen Tag (oder was auch immer der exact -Typ von mydate ist) auf sysdate - 5 ?
Tags und Links sql oracle performance oracle9i