У меня супер-простой запрос в схеме «звезда». Один факт, два измерения. Я проверил, что я делаю соединения правильно. Но когда я выполняю план запроса, я получаю декартово объединение слиянием непосредственно перед шагами по добавлению измерений.
explain plan for
select * from fact f
inner join dim1 d1
on d1.id = f.d1_id
inner join dim2 d2
on d2.id = f.d2_id
where d1.code = 'A' and d2.code = 'B';
Если я перейду к поиску по идентификатору измерения вместо кода, у меня все в порядке - нет декартовой системы.
explain plan for
select * from fact f
inner join dim1 d1
on d1.id = f.d1_id
inner join dim2 d2
on d2.id = f.d2_id
where d1.id= '1' and d2.id = '2';
Есть идеи, что может привести к возникновению декартовой системы?
EDIT:
Я только что создал таблицы и индексы сегодня. Я проверю, что я «вычислял статистику» по ним, чтобы быть уверенным, что все обновлено.
больше информации о таблицах теперь, когда я отредактировал их и избавился от декартовой системы:
Таблица фактов:
индекс растрового изображения на dim1.id
индекс растрового изображения на dim2.id
(и еще много растровых индексов)
Dim1
уникальный индекс по id
индекс растрового изображения в коде - это ново, но похоже, что оно не изменило план запроса.
Dim2
уникальный индекс по id
уникальный индекс по коду - когда я добавил это, декартово число исчезло.
Моя таблица фактов содержит 50 миллионов записей, в dim1 - 44 записи, а в dim2 - 6 записей. Поэтому у меня изначально не было индексов для таких коротких таблиц. Но добавление уникального индекса в dim2 избавило от декартового объединения и снизило оценку времени плана запроса с 5 до нескольких секунд.