2016-05-22 3 views
0

Может кто-нибудь помочь в решении моей проблемы У меня есть три таблицы, которые нужно объединить с помощью индексов в Teradata для повышения производительности. Запрос, указанный ниже: -Нужно применять первичные индексы и вторичные индексы в таблицах терадата

Select b.Id, b.First_name, b.Last_name, c. Id, 
    c.First_name, c.Last_name, c.Result 
from 
(
    select a.Id, a.First_name, a. Last_name, a.Approver1, a.Approver2 
    From table1 a 
    Inner join table2 d 
    On a.Id =D.Id 
    and A.Approver1 =a.Approver1 
    And a.Approve2 =D.Approver2 
) b 
Left join 
(
    select * from table3 
    where result is not null 
    and application like 'application1' 
) c 
On c. Id=b.Id 
Group by b.Id, b.First_name, b.Last_name, c.Id, 
    c.First_name, c.Last_name, c.Result 

Вышеуказанный запрос занимает столько времени, что PI не определен правильно. Первые две таблицы (таблица 1 и 2) имеют одинаковый набор столбцов, поэтому pi можно определить как PI на I, одобрить1, approve2 Однако, когда соединение с таблицей 3 запутано и нужно понять, как определить pi. Это то, что PI может работать только тогда, когда у нас есть один и тот же набор столбцов в таблицах?

Структура Table3 является я, фамилия, имя, результат

и таблица 1 и table2 Id, имя, фамилия, Подтвердили 1, Approved 2, Результаты

Может вы поможете в определении первичных индексов, чтобы можно было оптимизировать запрос.

ответ

1

Teradata обычно не использует вторичные индексы для объединений. Лучший PI был бы id для всех трех таблиц, конечно, вам нужно проверить, не слишком ли много строк на значение, и оно не слишком искажено.

GROUP BY можно упростить до DISTINCT, зачем вам это нужно, можете ли вы показать первичные ключи этих таблиц?

Редактировать на основе комментариев:

PI на основе соединения являются, безусловно, самым быстрым способом. Но вы должны быть в состоянии избавиться от DISTINCT, тоже, это всегда огромные накладные расходы.

Попробуйте заменить 1-ый присоединиться с NOT EXISTS:

Select b.Id, b.First_name, b.Last_name, c. Id, 
    c.First_name, c.Last_name, c.Result 
from 
(
    select a.Id, a.First_name, a. Last_name, a.Approver1, a.Approver2 
    From table1 a 
    WHERE EXISTS 
    ( 
     SELECT * 
     FROM table2 d 
     WHERE a.Id =D.Id 
     and A.Approver1 =a.Approver1 
     And a.Approve2 =D.Approver2 
    ) 
) b 
Left join 
(
    select * from table3 
    where result is not null 
    and application like 'application1' 
) c 
On c. Id=b.Id 
+0

Как сейчас, первичный ключ присваивается SNO столбец, который был добавлен при создании таблицы. Тем не менее, да, я могу сказать, что данные массивны, и объединение выше трех таблиц влияет на производительность терадаты .... Если бы я назначил, то я был бы pi, тогда вы думаете, что это будет сортировать проблему? Я спросил, так как первое присоединение связано с дубликатами данных. Много дубликатов. И разные не делали, так как не вся строка - это дубликат. Может быть другой утвердитель для того же ID –

+0

@puneetmadan: Если у вас есть дубликаты, у вас нет Первичного ключа :) Я только что отредактировал свой ответ. Кстати, что такое * массивный *? – dnoeth

+0

Спасибо, я бы использовал приведенный выше код. Но я забыл упомянуть, что таблица 3 также доступна с дубликатами. Например: - у меня было бы 1 и приложение «приложение», и я бы 1 мог иметь множественный доступ к приложению, поэтому я бы 1 был там в данных более одного раза, но приложение также, но так как пользователь имеет множественный доступ к приложению, поэтому в данных было бы больше одной записи. И имя приложения также содержится в таблице 1 и 2. Пожалуйста, дайте мне знать, если я должен предоставить вам полные структуры таблиц для всех таблиц, которые будут объединены. Заранее спасибо –

Смежные вопросы