Много ли повторяющихся сумм (x) в разных столбцах замедляет процесс выбора?

Question

У меня действительно большая таблица с десятками столбцов и множеством строк.Давайте назовем эту таблицу FT.Каждый день я запускаю сценарий, который читает данные из таблицы FT, выполняет некоторые вычисления и обновляет меньшую таблицу (таблицу FA), которую я использую для создания отчетов.

Запрос, который обновляет FA, выглядит примерно так:*

INSERT INTO FA (A, B, C) 
    (SELECT sum(X), sum(x) * sum(y), sum(x) + sum(z)) group by..

Поскольку я часто использую sum (x), будет ли быстрее, если я создам временную таблицу с суммами (x), sum (y) и sum (z) и использую ее для обновления моегоТаблица FA?

Answer 1

Как правило, время, необходимое для извлечения данных с диска, является самой медленной операцией, выполняемой базой данных (особенно для большой таблицы)

Я ожидаю, что относительно простые арифметические операции, подобные этим, будут пренебрежимо малы по сравнению.

Answer 2

каждый дБ, который я знаю, оптимизировал этот вид thign, поэтому значения рассчитываются только один раз.

, если вы не уверены, посмотрите на план выполнения и чтения для текущего запроса, и вы изменили на tempзапрос таблицы.

Answer 3

Учитывая, что вы пометили этот пост data-warehouse и datamart, я могу только предположить, что ваша таблица FT является неким фактом и что запрос выглядит примерно так:

select 
    CalendarMonth
  , sum(x) as Tot_1 
  , sum(x) * sum(y) as Tot_2
  , sum(x) + sum(z) as Tot_3
from FT         as f
join dimDate    as d on d.DateKey    = f.DateKey
join dimUser    as u on u.UserKey    = f.UserKey
join dimProduct as p on p.ProductKey = f.ProductKey
where CalendarYear between 2008 and 2010
  and Country = 'United States'
  and ProductCategory = 'Cool Gadget'
  and UserGender = 'Female'
group by CalendarMonth ;

Именно так должна выглядеть агрегация по показателям в таблице фактов.

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

Например, если у вас есть 10 000 продаж в день, сумма запроса выше ~ 300 000 строк за каждый месяц. Если таблица агрегации агрегируется за день, то для обновления таблицы требуется сумма в 10 000 строк один раз в день, а для отчета - всего 30 строк в месяц.

Подводя итог, можно сказать, что для ускорения запросов по агрегации фокусируются на количестве агрегируемых строк, а не на функциях агрегирования. Также убедитесь, что таблицы измерений имеют индексы для столбцов, упомянутых в предложении WHERE запроса.

Правда, я мог бы предположить, что здесь слишком много, так что это может или не может быть полезным.

Answer 4

Сравните ваш запрос с:

insert into fa (a, b, c)
select sum_x, sum_x * sum_y, sum_x * sum_z
  from (select sum(x) as sum_x, sum(y) as sum_y, sum(z) as sum_z
          from my_table
         group by my_grouping_columns)

Я сильно подозреваю, что Oracle должен сначала построить промежуточный набор независимо от сумм, сгруппированных в, а затем преобразовать их в окончательный набор результатов, независимо.

Определенно не будет проще или быстрее заставить Oracle материализовать промежуточный набор результатов в глобальную временную таблицу;вы добавляете прямой путь ввода / вывода без веской причины для этого.Тем не менее, если промежуточный набор результатов является дорогим для построения и использования в нескольких вставках, может оказаться целесообразным материализовать его во временную таблицу.