Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2006.10.22;
Скачать: CL | DM;

Вниз

Сложный JOIN таблиц   Найти похожие ветки 

 
palva ©   (2006-08-25 17:48) [0]

Сабж встречается у меня в хранимой процедуре - четыре таблицы, одна из них два раза. Стоит ли попытаться сделать все это несколькими запросами с хранением промежуточных результатов в переменных? Или оптимальнее будет оставить сложный запрос?


 
StriderMan ©   (2006-08-25 17:50) [1]

Если JOIN по индексированным полям, то лучше конечно JOIN.


 
ANB ©   (2006-08-25 17:56) [2]


> Если JOIN по индексированным полям

А если не по индексированным - проидексировать и все равно JOIN.


 
palva ©   (2006-08-25 17:58) [3]

Отдельные запросы ведь тоже будут использовать индексы. У меня впечатление, что оптимизатор кода процедур существенно хуже работает, чем оптимизатор запросов.


 
ANB ©   (2006-08-25 18:01) [4]


> palva ©   (25.08.06 17:58) [3]

4 курсора по маленьким запросам везде работают помедленнее, чем один по большому. Ресурсы типа жрут и все такое. Я разбиваю на куски либо если оракла не дает запрос впихнуть в хранимку, либо если мозгов не хватает грамотно запрос написать. Кстати, потери небольшие, а вот если большой запрос плохо написать, то тормоза будут еще больше.
Но на 4-х таблицах - это довольно простой запрос.


 
unknown ©   (2006-08-25 18:18) [5]


> palva ©   (25.08.06 17:58) [3]

Что мешает поэксперементировать? Сделать так и так и так и...
При этом проанализировать планы, время выполнения, количество чтений и т.п.


 
palva ©   (2006-08-25 20:07) [6]

> Что мешает поэксперементировать?
Не врубился в это пока.


 
Desdechado ©   (2006-08-27 15:59) [7]

palva ©   (25.08.06 17:48)
Если логика запроса не вывихнутая, то лучше одним запросом обойтись. Если же вывихи есть, развесь их по отдельным (возможно, вложенным) запросам.

> ANB ©   (25.08.06 18:01) [4]
Я заметил, что Оракл начинает тупить с планами запросов, когда используется более 6 таблиц в одном запросе. Тогда оптимизатор просто не успевает или не желает рассматривать все дерево вариантов планов и получаются "кривульки". Разбиением этих запросов часто скорости увеличиваются на порядок.

Как с этим у IB/FB, не замечал.


 
evvcom ©   (2006-08-28 09:07) [8]

> [7] Desdechado ©   (27.08.06 15:59)
> Я заметил, что Оракл начинает тупить с планами запросов,
> когда используется более 6 таблиц в одном запросе. Тогда
> оптимизатор просто не успевает или не желает рассматривать
> все дерево вариантов планов и получаются "кривульки".

Количество всех вариантов планов равно (Ntab - 1)! Естественно, что все варианты перебирать - это терять кучу времени на переборах. По-моему, оракл перебирает всего не более 20 вариантов, причем вроде как не все подряд, а по его оценкам возможных кандидатов. Иногда он неверно оценивает количество записей из-за параметров или участия в запросе пользовательских функций и/или таблиц-функций. В таких случаях я ему помогаю хинтами :), но все равно стараюсь делать это в одном запросе.


 
Desdechado ©   (2006-08-28 10:46) [9]

> оракл перебирает всего не более 20 вариантов
Зависит от настроек Оракла.


 
Sergey13 ©   (2006-08-28 10:59) [10]

Что то частенько обсуждение вопросов по любым БД стало перескакивать на Оракл.
К чему бы это? 8-)


 
palva ©   (2006-08-28 15:18) [11]

Спасибо всем.



Страницы: 1 вся ветка

Текущий архив: 2006.10.22;
Скачать: CL | DM;

Наверх




Память: 0.49 MB
Время: 0.04 c
15-1159441851
Palladin
2006-09-28 15:10
2006.10.22
Авторизация на сервере


15-1159464326
AntiUser
2006-09-28 21:25
2006.10.22
А как упростить запрос


15-1159686860
Kerk
2006-10-01 11:14
2006.10.22
Олигархи


1-1157456048
AndreyRu
2006-09-05 15:34
2006.10.22
Рисование штрихкода


2-1160387648
Steep[on work]
2006-10-09 13:54
2006.10.22
Ссылка