Wenn Sie Bind-Variablen verwenden, ist Oracle gezwungen, zu verwenden dynamisches Partitions-Pruning statt statisches Partitions-Pruning . Das Ergebnis davon ist, dass Oracle zum Zeitpunkt der Analyse nicht weiß, auf welche Partitionen zugegriffen wird, da sich dies basierend auf Ihren Eingabevariablen ändert.
Das bedeutet, dass wir bei der Verwendung von Literalwerten (anstelle von Bind-Variablen) wissen, auf welche Partitionen von Ihrem lokalen Index zugegriffen wird. Daher der count stopkey kann auf die Ausgabe des Index angewendet werden, bevor wir die Partitionen bereinigen.
Bei Verwendung von Bind-Variablen der partition range iterator muss herausfinden, auf welche Partitionen Sie zugreifen. Es wird dann überprüft, ob die erste Ihrer Variablen in den Zwischenoperationen tatsächlich einen niedrigeren Wert hat als die zweite (der filter Betrieb im zweiten Plan).
Dies lässt sich leicht nachvollziehen, wie der folgende Testfall zeigt:
create table tab (
x date,
y integer,
filler varchar2(100)
) partition by range(x) (
partition p1 values less than (date'2013-01-01'),
partition p2 values less than (date'2013-02-01'),
partition p3 values less than (date'2013-03-01'),
partition p4 values less than (date'2013-04-01'),
partition p5 values less than (date'2013-05-01'),
partition p6 values less than (date'2013-06-01')
);
insert into tab (x, y)
select add_months(trunc(sysdate, 'y'), mod(rownum, 5)), rownum, dbms_random.string('x', 50)
from dual
connect by level <= 1000;
create index i on tab(x desc, y desc) local;
exec dbms_stats.gather_table_stats(user, 'tab', cascade => true);
explain plan for
SELECT * FROM (
SELECT rowid FROM tab
where x between date'2013-01-01' and date'2013-02-02'
and y between 50 and 100
order by x desc, y desc
)
where rownum <= 5;
SELECT * FROM table(dbms_xplan.display(null, null, 'BASIC +ROWS +PARTITION'));
--------------------------------------------------------------------
| Id | Operation | Name | Rows | Pstart| Pstop |
--------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | |
| 1 | COUNT STOPKEY | | | | |
| 2 | VIEW | | 1 | | |
| 3 | SORT ORDER BY STOPKEY | | 1 | | |
| 4 | PARTITION RANGE ITERATOR| | 1 | 2 | 3 |
| 5 | COUNT STOPKEY | | | | |
| 6 | INDEX RANGE SCAN | I | 1 | 2 | 3 |
--------------------------------------------------------------------
explain plan for
SELECT * FROM (
SELECT rowid FROM tab
where x between to_date(:st, 'dd/mm/yyyy') and to_date(:en, 'dd/mm/yyyy')
and y between :a and :b
order by x desc, y desc
)
where rownum <= 5;
SELECT * FROM table(dbms_xplan.display(null, null, 'BASIC +ROWS +PARTITION'));
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Pstart| Pstop |
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | |
| 1 | COUNT STOPKEY | | | | |
| 2 | VIEW | | 1 | | |
| 3 | SORT ORDER BY STOPKEY | | 1 | | |
| 4 | FILTER | | | | |
| 5 | PARTITION RANGE ITERATOR| | 1 | KEY | KEY |
| 6 | INDEX RANGE SCAN | I | 1 | KEY | KEY |
---------------------------------------------------------------------
Wie in Ihrem Beispiel kann die zweite Abfrage die Partitionen nur nach einem key filtern zur Parsing-Zeit und nicht die genauen Partitionen wie im ersten Beispiel.
Dies ist einer der seltenen Fälle, in denen Literalwerte eine bessere Leistung bieten können als Bind-Variablen. Sie sollten prüfen, ob dies für Sie möglich ist.
Schließlich sagen Sie, Sie möchten 20 Zeilen von jeder Partition. Ihre Abfrage als Ständer tut dies nicht, sie gibt Ihnen nur die ersten 20 Zeilen gemäß Ihrer Reihenfolge zurück. Für 20 Zeilen/Partition müssen Sie etwa so vorgehen:
select rd from (
select rowid rd,
row_number() over (partition by trx_id order by create_ts desc) rn
from OUT_SMS
where TRX_ID between ? and ?
and CREATE_TS between ? and ?
order by CREATE_TS DESC, TRX_ID DESC
) where rn <= 20
AKTUALISIEREN
Der Grund, warum Sie den count stopkey nicht erhalten hat mit dem filter zu tun Operation in Zeile 4 des "bösen" Plans. Sie können dies deutlicher sehen, wenn Sie das obige Beispiel wiederholen, aber ohne Partitionierung.
Dadurch erhalten Sie die folgenden Pläne:
----------------------------------------
| Id | Operation | Name |
----------------------------------------
| 0 | SELECT STATEMENT | |
|* 1 | COUNT STOPKEY | |
| 2 | VIEW | |
|* 3 | SORT ORDER BY STOPKEY| |
|* 4 | TABLE ACCESS FULL | TAB |
----------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM<=5)
3 - filter(ROWNUM<=5)
4 - filter("X">=TO_DATE(' 2013-01-01 00:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "X"<=TO_DATE(' 2013-02-02 00:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "Y">=50 AND "Y"<=100)
----------------------------------------
| Id | Operation | Name |
----------------------------------------
| 0 | SELECT STATEMENT | |
|* 1 | COUNT STOPKEY | |
| 2 | VIEW | |
|* 3 | SORT ORDER BY STOPKEY| |
|* 4 | FILTER | |
|* 5 | TABLE ACCESS FULL | TAB |
----------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM<=5)
3 - filter(ROWNUM<=5)
4 - filter(TO_NUMBER(:A)<=TO_NUMBER(:B) AND
TO_DATE(:ST,'dd/mm/yyyy')<=TO_DATE(:EN,'dd/mm/yyyy'))
5 - filter("Y">=TO_NUMBER(:A) AND "Y"<=TO_NUMBER(:B) AND
"X">=TO_DATE(:ST,'dd/mm/yyyy') AND "X"<=TO_DATE(:EN,'dd/mm/yyyy'))
Wie Sie sehen können, gibt es einen zusätzlichen filter Vorgang, wenn Sie Bind-Variablen verwenden, die vor der sort order by stopkey erscheinen . Dies geschieht nach dem Zugriff auf den Index. Dies prüft, ob die Werte für die Variablen die Rückgabe von Daten zulassen (die erste Variable in Ihrem between hat tatsächlich einen niedrigeren Wert als die zweite). Dies ist bei der Verwendung von Literalen nicht erforderlich, da der Optimierer bereits weiß, dass 50 kleiner als 100 ist (in diesem Fall). Es weiß jedoch nicht, ob :a kleiner als :b zur Parse-Zeit ist.
Warum das genau so ist, weiß ich nicht. Es könnte ein absichtliches Design von Oracle sein - es hat keinen Sinn, die Stopkey-Prüfung durchzuführen, wenn die für die Variablen festgelegten Werte zu Nullzeilen führen - oder nur ein Versehen.
