Есть такая задача:
разработчики софта обратились ко мне с вопросом
1) есть необходимость делать объединения по нескольким таблицам
2) сама структура каждой из таблиц заранее неизвестна
3) у каждой таблицы есть первичный ключ ROW16
4) объединения идут по первичному ключу
5) FK между таблицами обеспечивается на уровне Application Server. Разработчики гарантируют что сбоев в работе FK не будет.
7) размер таблиц до нескольких сот тысяч строк
8) обновления данных редкие
9) запросы надо создавать динамически (программно)
Вот пример такого запроса
1.
2.
3.
4.
5.
6.
select * from
(SELECT
main.id, main.name1, a_id, b_id, c_id, dict_a.name1 as a_name1, dict_b.name1 as b_name1, dict_c.name1 as c_name1
FROM main, dict_a, dict_b, dict_c
WHERE main.a_id = dict_a.id and main.b_id = dict_b.id and main.c_id = dict_c.id AND ( main.id > '0000000000000000')
ORDER BY name1, main.id )
WHERE rownum <= 40
Время обработки такого запроса ужасающе - более минуты
Нужно минимизировать время исполнения.
________________________________________
Я предложил
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
select * from
(SELECT
main.id, main.name1, a_id, b_id, c_id, dict_a.name1 as a_name1, dict_b.name1 as b_name1, dict_c.name1 as c_name1
FROM
(Select * from
(Select id, name1, a_id, b_id, c_id from main
Where main.id > '0000000000000000'
ORDER BY name1, id
) WHERE rownum <= 40
)
main, dict_a, dict_b, dict_c
WHERE main.a_id = dict_a.id and main.b_id = dict_b.id and main.c_id = dict_c.id
)
И увеличить Sort_aria_size
____________________________________
Мне кажется что это не единственное и не наилучшее решение. Однако ничего другого универсального я предложить не могу.
Кстати мне показалось интересным что ни в первом ни во втором случае план исполнения не показывает обращения к индексам таблицы MAIN. Почему?
Еще интересно что увеличением sort_aria_size я добился ускорения в несколько раз и всё. Дальнейшее увеличение ни к чему не ведет, хотя оперативная память еще есть.
К вышесказанному сильно используется Temproary tablespace. Неужели нельзя добиться чтобы для исполнения запроса не требовалось до 200M во временном пространстве.
Еще замечание хинт FirstRows замедляет выполнение запроса по сравнению с AllRows. Незначительно но замедляет. Почему если нужно всего 40 строк из 100000 хинт так работает.
Буду благодарен за любые высказывания.
