Оптимизация запроса к DB2

← →
Оптимайзер (2008-12-17 14:12) [0]

Подскажите новичку, как оптимизировать такой запрос?

select DOCINP.DCINMB as DCINMB, DOCINP.DCIDCK as DCIDCK, DOCINP.DCICPY as DCICPY, DOCINP.DCITYP as DCITYP, DOCINP.DCICND as DCICND, GMDOCTYPE.DOCS_ID as DOCTYPE, GMDOCTYPE.SEND_AIM as SEND_AIM, GMDOCTYPE.CHECK_INS as CHECK_INS from DISTDB.DOCINP DOCINP, CLSDB.GMDOCS GMDOCS, CLSDB.GMDOCTYPE GMDOCTYPE, CLSDB.GMVER GMVER where (DOCINP.DPTCOD = :dptcod) and (DOCINP.DCICND in ("ПРОВ", "ПАЧК", "ВКЛЧ")) and (DOCINP.DCIERR = "ПРАВ") and ((DOCINP.DCITRN is NULL) or (DOCINP.DCITRN = "")) and (DOCINP.DCITYP = GMDOCS.TYPE) and (GMDOCS.ID = GMVER.DOCID) and (GMVER.VCODE = GMDOCTYPE.DOCS_ID) and (GMVER.ACTIVE = "Y") order by DCINMB ASC, DCIDCK ASC, DCICPY ASC;

← →
Sergey13 © (2008-12-17 14:28) [1]

Запросы обычно оптимизируются для КОНКРЕТНЫХ условий, а не просто так.
Что за таблицы, какие инедксы, сколько записей в таблицах и в результате? Что конкретно тормозит?

← →
clickmaker © (2008-12-17 14:32) [2]

> "ПРОВ", "ПАЧК", "ВКЛЧ"

это некий фиксированный набор или произвольные слова?
в первом случае я бы сделал справочник и искал бы по ID

← →
Johnmen © (2008-12-17 14:41) [3]

Запрос вообще неверный. Т.к. как минимум нет связи таблицы DOCINP с остальными.

← →
Кщд (2008-12-17 14:43) [4]

>Johnmen © (17.12.08 14:41) [3]
DOCINP.DCITYP = GMDOCS.TYPE

← →
Оптимайзер (2008-12-17 15:00) [5]

Таблица DISTDB.DOCINP - от полумиллиона до миллиона записей (и они продолжают довольно быстро накапливаться)
Поля:
DPTCOD - BigInt, PK
DCINMB - Double(11, 0), PK
DCIDCK - SmallInt, PK
DCICPY - SmallInt, PK
DCITYP - Char(4)
DCICND - Char(4)
DCIERR - Char(4)
DCITRN - Char(4)

Таблица CLSDB.GMDOCS - около сотни записей
Поля:
ID - BigInt, PK
TYPE - Char(4)

Таблица CLSDB.GMDOCTYPE - около сотни записей
Поля:
ID - BigInt, PK
DOCS_ID - BigInt, Unique
SEND_AIM - SmallInt
CHECK_INS - SmallInt

Таблица CLSDB.GMVER - несколько сотен записей
Поля:
DOCID - BigInt, PK
VCODE - BigInt, PK
ACTIVE - Char(1)

Индексов нет.

← →
Оптимайзер (2008-12-17 15:05) [6]

В таблицах есть еще и другие поля, но в данном запросе они не участвуют.

← →
Sergey13 © (2008-12-17 15:15) [7]

> [5] Оптимайзер (17.12.08 15:00)
> Индексов нет.

Круто!

← →
Оптимайзер (2008-12-17 15:18) [8]

В результате ожидается до сотни записей.

Что тормозит - неясно. Запрос может выполняться от секунды до 5-7 минут. Причина непонятна.

← →
Правильный$Вася (2008-12-17 15:45) [9]

по первичному ключу не может не быть индекса, причем уникального
иначе субд просто не проконтролирует уникальность
не, теоретически полный перебор для ее проверки она может делать, но вряд ли db2 настолько тупая

← →
Правильный$Вася (2008-12-17 15:49) [10]

> DOCINP.DCICND in ("ПРОВ", "ПАЧК", "ВКЛЧ")) and (DOCINP.DCIERR = "ПРАВ") and

а это можно было бы и проиндексировать

> clickmaker © (17.12.08 14:32) [2]

смысла нет
поля 4-символьные, по длине - как обычное число
поэтому делать еще один справочник не оправдано, только добавит тормозов

← →
ANB (2008-12-17 16:28) [11]

> Запрос может выполняться от секунды до 5-7 минут.

5-7 минут - первое выполнение.
Секунда - данные закэшировались и все летает.

← →
Оптимайзер (2008-12-17 16:38) [12]

> ANB (17.12.08 16:28) [11]

Если бы это было так...

← →
ANB (2008-12-17 17:55) [13]

> Оптимайзер (17.12.08 16:38) [12]

Так оно и есть. Если тока одна толстая таблица, то надо бы повесить на нее индексы. И внимательно посмотреть связки - нету ли ненужного кортезиана (не забыл ли подвязать какую нибудь табличку).

> Оптимайзер (17.12.08 16:38) [12]

начни с
select * from DISTDB.DOCINP where (DOCINP.DPTCOD = :dptcod)
начинай наворачивать остальное, посмотри, когда появятся тормоза.

Оптимизация запроса к DB2 Найти похожие ветки