Имеем ASA 9.0.2.3044
Есть 2 таблицы – операций и проводок со связью 1 ко многим :
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
create table OPS
(OPS_ID integer not null default autoincrement,
DAT date not null,
CST_ID integer,
.
.
.
primary key (OPS_ID));
create table COR (
cor_id integer not null default autoincrement,
OPS_ID integer,
DB char( 5 ) not null,
CR char( 5 ) not null,
S_P numeric( 12 , 2 ) not null default 0 . 0 ,
.
.
.
primary key (cor_id)
);
alter tableCOR
add constraint foreign key (OPS_ID)
references OPS (OPS_ID)
on update cascade
on delete cascade;
Для построения отчета выбираются операции определенного контрагента за период по заданному счету в проводках. Запрос примерно такой
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SELECT OPS.DAT,
(select sum(s_p) from cor c
where c.ops_id=ops.ops_id and c.db ='3611' ) as SUM_DB,
(select sum(s_p) from cor c
where c.ops_id=ops.ops_id and c.cr ='3611' ) as SUM_CR,
(select name from cst where cst_id= 350 ),
.
.
.
from ops
where OPS.DAT between dbeg and dend ) and OPS.CST = 350
and (SUM_DB<> 0 OR SUM_CR<> 0 )
Поскольку за период могут быть операции этого контрагента не затрагивающие интересующий нас счет их и отсекли условием :
and (SUM_DB<>0 OR SUM_CR<>0)
Я понимаю, что решение идеологически неправильное, но В ASA 7.xx и A8.xx все прекрасно работало. Под 9 такой запрос тормозит в сотни раз :(
Стоило заменить последнее условие на
1.
exists(select 1 from cor where cor.ops_id=ops.ops_id AND (cr ='3611' or db ='3611'))
как запрос стал летать. Вместо 15…20 минут выполняется за 2..5 секунд.
В первой таблице около 50 000 строк, во второй около 160 000. В выборку попадает от 2 до 15 строк из первой таблицы и 20…30 строк из второй .
Что это – глюк оптимизатора ? План запроса никаких дырок не показывает. Все таблицы сканируются по индексам (с приличной селективностью)
Реальный запрос более сложный и есть необходимость строить его именно по таблице операций.
И я знаю примерно 5 вариантов, как правильно его переписать :-)).
Напрягает, что это уже не первая проблема с подзапросами при переходе на 9 версию :(.
Что-то они все-таки намудрили с оптимизацией аггрегирующих функций :(
