-
Подскажите новичку, как оптимизировать такой запрос?
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;
-
Запросы обычно оптимизируются для КОНКРЕТНЫХ условий, а не просто так.
Что за таблицы, какие инедксы, сколько записей в таблицах и в результате? Что конкретно тормозит?
-
> 'ПРОВ', 'ПАЧК', 'ВКЛЧ'
это некий фиксированный набор или произвольные слова?
в первом случае я бы сделал справочник и искал бы по ID
-
Запрос вообще неверный. Т.к. как минимум нет связи таблицы DOCINP с остальными.
-
>Johnmen © (17.12.08 14:41) [3]
DOCINP.DCITYP = GMDOCS.TYPE
-
Таблица 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)
Индексов нет.
-
В таблицах есть еще и другие поля, но в данном запросе они не участвуют.
-
> [5] Оптимайзер (17.12.08 15:00)
> Индексов нет.
Круто!
-
В результате ожидается до сотни записей.
Что тормозит - неясно. Запрос может выполняться от секунды до 5-7 минут. Причина непонятна.
-
по первичному ключу не может не быть индекса, причем уникального
иначе субд просто не проконтролирует уникальность
не, теоретически полный перебор для ее проверки она может делать, но вряд ли db2 настолько тупая
-
> DOCINP.DCICND in ('ПРОВ', 'ПАЧК', 'ВКЛЧ')) and (DOCINP.DCIERR = 'ПРАВ') and
а это можно было бы и проиндексировать
> clickmaker © (17.12.08 14:32) [2]
смысла нет
поля 4-символьные, по длине - как обычное число
поэтому делать еще один справочник не оправдано, только добавит тормозов
-
> Запрос может выполняться от секунды до 5-7 минут.
5-7 минут - первое выполнение.
Секунда - данные закэшировались и все летает.
-
> ANB (17.12.08 16:28) [11]
Если бы это было так...
-
> Оптимайзер (17.12.08 16:38) [12]
Так оно и есть. Если тока одна толстая таблица, то надо бы повесить на нее индексы. И внимательно посмотреть связки - нету ли ненужного кортезиана (не забыл ли подвязать какую нибудь табличку).
-
> Оптимайзер (17.12.08 16:38) [12]
начни с
select * from DISTDB.DOCINP where (DOCINP.DPTCOD = :dptcod)
начинай наворачивать остальное, посмотри, когда появятся тормоза.
|
Есть новые 
Нет новых [134477 +39][b:0][p:0.002]