Есть набор запросов по схеме:
SELECT DT.ID, DT.DOC_NUM
FROM EXP.DOC_TITLE DT
WHERE DT.AFFILIATE = ? AND DT.DEPOTSECTOR = ?
AND EXISTS(SELECT B.DOC_TITLE FROM EXP.DOC_BODY B
INNER JOIN EXP.FILTER_GOODS_USER FF1 ON (FF1.GOODS = B.GOODS)
WHERE B.DOC_TITLE = T.ID)
Могут меняться таблицы EXP.DOC_TITLE & EXP.DOC_BODY, но их структуры во многом схожи.
Просматривая планы запросов видно, что чаще всего сканирование таблицы EXP.DOC_BODY (а вернее только её уникального индекса) идет по предикатам (EXP.DOC_BODY.DOC_TITLE = ? & EXP.DOC_BODY.GOODS = ?). Но бывает и так что сканирование этой таблицы идет полностью(!).
Может, у кого есть предположения в связи с чем может возникнуть такая разница в поведении. И как её заставить сканировать используя предикаты?
Попробуй собрать статистику (runstats) по таблицам, включая статистику по распределению (WITH DISTRIBUTION) по столбцам, на которых используются предикаты.
Пробовал. Не помогает.
Помогает если поставить SET CURRENT QUERY OPTIMIZATION = 3
Но что-то не совсем мне это нравится, хочется оставить по default=5 (может, зря?).
Складывается мнение что DB2 решает, что запрос лучше выполнить просканировав индекс полностью и затем присоединить его, выполнив ограничения.
Затраты в таймеронах при этом выгядят:
IXSCAN - 13168 затем MSJOIN - 34 (?)
От этого можно избавиться другим способом? И в чем может быть причина такого поведения?
На самом деле всe зависит от типа твоего приложения. Например IBM-кая лаборатория которая IBM Content Manager разрабатывает постала для него Def optimisation level 3 и очень не рекомендует его менять. Тоже самое для SAP.
Поставь для своего приложения DEF OPT level 3. А если надо будет выше через SET CURRENT QUERY OPTIMIZATION повышаешь как тебе ужно.
