Desert_NomadНу тогда поделюсь линком, да не сочтут меня достойные модераторы за рекламщика сторонних ресурсов и не буду я за это больно бит, может даже ногами (с):
http://www.fors.ru/upload/magazine/07/http_text/russia_mihjeichev_plan_recomendations.html
все равно лень комментировать все ошибки там, поэтому отвечу только по поводу популярного заблуждения
http://www.fors.ru/upload/magazine/07/http_text/russia_mihjeichev_plan_recomendations.html При анализе план просматриваетcя
снизу вверх .
Читай тут:
19813880
Продублирую с небольшой правкой и дополнением:
Проще всего объяснять, что каждая строка плана - это вызов некой функции. Собственно, V$SQL_PLAN.OPERATION - это название функции, а V$SQL_PLAN.OPTIONS - это параметр, определяющий ее алгоритм/подфункцию.
чуть подробнееНапример, операция "TABLE ACCESS" имеет следующие варианты:
BY GLOBAL INDEX ROWID BATCHED
BY INDEX ROWID
BY INDEX ROWID BATCHED
BY LOCAL INDEX ROWID BATCHED
BY USER ROWID
CLUSTER
FULL
SAMPLE
А у INDEX:
FAST FULL SCAN
FULL SCAN
FULL SCAN (MIN/MAX)
RANGE SCAN
RANGE SCAN (MIN/MAX)
RANGE SCAN DESCENDING
SAMPLE FAST FULL SCAN
SKIP SCAN
UNIQUE SCAN
Т.к. алгоритмы совершенно разные, то и смысла называть только OPERATION без OPTIONS не имеет, поэтому DBMS_XPLAN как и другие инструменты их конкатенируют, например TABLE ACCESS FULL, TABLE ACCESS BY INDEX ROWID. И мы говоря о FULL TABLE SCAN имеем ввиду функцию TABLE ACCESS с параметром FULL.
Соответствие названий некоторых операций и реальных сишных функций можно увидеть в скрипте у Танела Подера:
http://blog.tanelpoder.com/files/scripts/tools/unix/os_explain
Короткий пример из os_explain
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
s/qerbm/MINUS: /g;
s/qercb/CONNECT BY: /g;
s/qerco/COUNT: /g;
s/qerfu/UPDATE: /g;
s/qerfx/FIXED TABLE: /g;
s/qergr/GROUP BY ROLLUP: /g;
s/qergs/GROUP BY SORT: /g;
s/qerhj/HASH JOIN: /g;
s/qeril/IN-LIST: /g;
s/qerix/INDEX: /g;
s/qerjot/NESTED LOOP JOIN: /g;
s/qerjo/NESTED LOOP OUTER: /g;
s/qerns/GROUP BY NO SORT: /g;
s/qeroc/OBJECT COLLECTION ITERATOR: /g;
s/qerso/SORT: /g;
s/qertb/TABLE ACCESS: /g;
s/qerua/UNION-ALL: /g;
s/qergh/HASH GROUP BY: /g
При необходимости каждая строка плана запускает, останавливает и обрабатывает дочерние операции. А каким именно образом и сколько раз она их запускает зависит от самой операции и ее параметров.
пара примеровНапример, HASH JOIN сначала вычитывает все результаты первой дочерней операции(build table) и только потом запускает вторую (prob table), a NESTED LOOPS получает строку из первой дочерней и для нее запускает вторую дочернюю, затем запускает снова первую, чтобы получить очередную строку и для нее снова вторую и тд...
Или еще более простой пример с select * from dual where 1=0
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 2 | 0 (0)| |
|* 1 | FILTER | | | | | |
| 2 | TABLE ACCESS FULL| DUAL | 1 | 2 | 2 (0)| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(NULL IS NOT NULL)
В данном случае операция FILTER не запускает дочерний TABLE ACCESS FULL, т.к. условие ложно
