|
|
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Есть запрос: SELECT 1 AS id, d.bvd_owner, d.form_sub, d.form_code, d.serial_number, '0' FROM t_operation o, t_bvd_data d WHERE o.id = d.operation AND o.operation_type IN ('Ca', 'Sa', 'Pe') AND o.is_basic_operation = 1 AND o.agency =19344 AND o.operation_date <='1.1.2003' В таблице t_operation есть индекс по operation_date и id, в таблице t_bvd_data есть индекс по operation. Смотрю на план запроса, пишет full scan, т.е. не использует индексы. В чем тут дело и как ускорить запрос? План запроса: SELECT STATEMENT, GOAL = CHOOSE 468 3031 127302 HASH JOIN 468 3031 127302 TABLE ACCESS FULL AGENCY T_OPERATION 117 3031 54558 TABLE ACCESS FULL AGENCY T_BVD_DATA 58 48067 1153608 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.03.2003, 09:28 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
А ты уверен, что хочешь чтобы он юзал индекс? Вобщем-то HASH JOIN один из самых быстрых способов объединения таблиц.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.03.2003, 09:47 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Я вижу что после hash join идет полный просмотр таблицы (table access full - это просмотр все таблицы?). И думаю что при использовании индексов запрос будет работать быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.03.2003, 09:58 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Ну во-первых посмотри сколько строк возвращает запрос и сколько строк в каждой из соединяемых таблиц. Если запрос возвращает больше половины строк, то фул скан уже оправдан. А во-вторых можно просто сравнить, поставь optimizer_mode=RULE и если хоть какой-то индекс ему подойдет он его подцепит. И сравнишь планы выполнения и время. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.03.2003, 10:04 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
В t_operation 49k записей, в t_bvd_data 48k. Запрос возвращает 0 записей. А как поставить optimizer_mode? На set optimizer_mode=RULE ругается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.03.2003, 10:11 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Погоди, у тебя что ни одна строка под условие не подпадает? Насчет RULE есть несколько вариантов. Можно alter session set otimizer_mode='RULE'; а можно хинт в запрос встроить: SELECT /*+ RULE */ 1 AS id, d.bvd_owner, d.form_sub, d.form_code... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.03.2003, 10:37 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Да, ни одна строка под условие не попадает. Это на что-то влияет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.03.2003, 11:16 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
> Да, ни одна строка под условие не попадает. Это на что-то влияет? Да, влияет. Дело в том, что, как правило, чтобы убедиться, что чего-то нет, нужно сделать полный просмотр того, где это что-то может лежать. У тебя условия по t_operation не возвращают ни одной записи, или именно джойн? Если первое, то пробуй вариант с хинтом RULE. А если джойн, то боюсь, что "в морг" -- при таких ценах HASH JOIN самый дешёвый вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2003, 23:53 |
|
||
|
Оптимизация запроса
|
|||
|---|---|---|---|
|
#18+
Если таблицы относительно статичны и нет большого риска одновременных изменений со стороны разных пользователей, то можно попробовать следующее: 1.Режим стоимостного оптимизатора 2.Создание битмап-индексов по полям operation_type, agency, is_basic_operation. 3.Cбор статистики по таблице и индексам. 4.Проверяем план и сравниваем результаты с исходной ситуацией. 5.Если результат положительный удаляем неиспользуемые индексы из п.2, если результат отрицательный то удаляем _все_ индексы из п.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2003, 15:46 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=32127894&tid=1991258]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
193ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
| others: | 248ms |
| total: | 554ms |

| 0 / 0 |
