Есть такой запрос:
1.
2.
3.
4.
select /*+ index(SM SVRM_SERVICE_IDX) */ S.SERVICE_ID
from TMP_INSTALL_BASE T
join SERVICES S on (S.TARIFF_ID = T.TARIFF_ID and S.STATUS != -20)
join BM_SERVICE_MONEY SM on (SM.SERVICE_ID = S.SERVICE_ID)
Выполняется практически мгновенно, возвращает меньше десятка записей.
Если убираю хинт, выполняется долго (3-4 минуты).
Планы с хинтом и без хинта отличаются (с хинтом INDEX RANGE SCAN и NL, без хинта INDEX FAST FULL SCAN и HASH JOIN).
В таблице BM_SERVICE_MONEY сотни миллионов записей. Каких-либо нестандартных вещей или больших изменений данных с ней не делалось.
Индекс SVRM_SERVICE_IDX составной (состоит из полей SERVICE_ID, FDATE).
Мне не совсем понятно, почему оптимизатор ошибается.
Трассировку 10053 я пока не делал, может быть тут есть какая-то очевидная причина?
Может быть нужно как-то задействовать поле FDATE, чтобы индекс был задействован?
При этом есть еще такой запрос, использующий результаты предыдущего запроса:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
with L as
(
select S.SERVICE_ID, sum(SM.SERVICE_AMOUNT) as QTY, sum(SM.MONEY) as SUM, trunc(max(SM.MOMENT)) as LAST, max(SM.TDATE) as END
from TMP_INSTALL_BASE T
join SERVICES S on (S.TARIFF_ID = T.TARIFF_ID and S.STATUS != -20)
join BM_SERVICE_MONEY SM on (SM.SERVICE_ID = S.SERVICE_ID)
where SM.PERIODIC_ACCT_ID is not null
group by S.SERVICE_ID
--having sum(SM.SERVICE_AMOUNT) >= 12
)
select S.SERVICE_ID--, S.LOGIN, S.RECKONING_DATE, S.START_DATE, S.STOP_DATE, L.QTY, L.SUM, L.LAST, L.END
from L
join SERVICES S on (S.SERVICE_ID = L.SERVICE_ID)
join CUSTOMERS C on (C.CUSTOMER_ID = S.CUSTOMER_ID)
join BM_CUSTOMER_CONTACT CC on (CC.CUSTOMER_ID = C.CUSTOMER_ID and CC.CONTACT_DICT_ID = 100)
join SERVICES S0 on (S0.ACCOUNT_ID = S.ACCOUNT_ID and S0.STATUS > 0 and S0.TARIFF_ID = 1 and S0.LOGIN = CC.VALUE)
join TMP_INSTALL_TARIFF ST on (ST.PARENT_ID = S.TARIFF_ID)
left join SERVICES SS on (SS.ACCOUNT_ID = S.ACCOUNT_ID and SS.STATUS != -20 and SS.TARIFF_ID = ST.TARIFF_ID)
Целиком он выполняется быстро (400мс после очистки кеша).
Но если убрать последнюю строку с LEFT JOIN, то выполнение занимает 3-4 минуты.
В этом тексте запроса FDATE вообще отсутствует.
