Hello, All!
Коллеги переводят большую БД с 1.5 на 2.1, и часть запросов стала
выполняться много медленнее.
В частном случае, поменялся порядок таблиц - натуралом сервер стал идти по
самой большой. Подробные данные ниже.
Из изменений, который могли повлиять я увидел только посегментную
статистику. И походже оптимизатору не на что опереться, для принятия
оптимального решения.
Ну а кол-во строк в таблице он не оценивает, та ведь?
Собсно вопрос - предположения правильны и выхода как кроме +0(вроде как там
запросов у них много) нет?
TABLE_BIG = 2млн (PSG)
TABLE_SMALL = 2тыс (SA)
TABLE_MEDIUM = 20тыс (PG)
select SUM(PG.DEBIT), COUNT(DISTINCT SA.ORGANIZATION_ID)
from TABLE_SMALL SA
join TABLE_BIG PG on pg.organization_id = sa.organization_id
join TABLE_MEDIUM PSG on psg.id = pg.drugs_id
where sa.cluster_id = :v_cluster_id and sa.type_org_id = :v_type_org_id
FB 1.5
plan join (sa natural, pg index (table_big_idx1), psg index
(pk_table_medium))
FB 2.1.1 (с последней одс, после рестора)
plan join (psg natural, pg index (table_big_idx3), sa index
(table_small_org_idx))
create index table_small_org_idx on table_small (organization_id);
(0,000577)
alter table table_medium add constraint pk_table_medium primary key (id);
(0,000049)
create index table_big_idx1 on table_big (organization_id, drugs_id);
(0,0000004)
селективность первого сегмента хуже TABLE_BIG_IDX1 = 0,000502260169
create index table_big_idx3 on table_big (drugs_id, type_org_id, city_id);
(0,00000111)
селективность первого сегмента TABLE_BIG_IDX3 = 0,0000373343282
--
-=Убежать от взрывной волны можно. Просто надо выбегать заранее.=-
With best regards, Nikolay Ponomarenko
