Группируйте, делая запрос астрономически длиннее

*Во-первых, у меня есть только доступ на чтение к моему серверу. Просто, к вашему сведению, как это, кажется, всплывает много...

Сервер: DB2 (6.1) for i (IBM)

У меня есть запрос, который я запускаю на таблице, которая имеет 19mil строк в нем (я не проектирую их, я просто запрашиваю их). Я ограничил свои возвращаемые данные 10 строками ( * ), пока не получу этот запрос, чтобы время возврата было немного более разумным.

Основной дизайн заключается в том, что мне нужно получить данные о категориях продуктов, которые мы продаем в неделю. по неделям, используя столбцы: WEEK_ID и CATEGORY. Вот пример кода (с некоторыми важными битами ####.) 

SELECT WEEK_ID, CATEGORY
FROM DWQ####.SLSCATW
INNER JOIN DW####.CATEGORY
ON DWQ####.SLSCATW.CATEGORY_NUMBER = DW####.CATEGORY.CATEGORY_NUMBER
WHERE WEEK_ID  
BETWEEN 200952 AND 201230 --Format is year/week
GROUP BY WEEK_ID, CATEGORY

Если я закомментирую эту последнюю строку, я могу получить обратно 100 строк за 254 МС. если я положу эту строку обратно в мое возвращение займет больше времени, чем у меня было терпение ждать :-). (Дольше всего я ждал 10 минут.)

Этот вопрос состоит из двух частей. Первый вопрос довольно рудиментарен: это нормально? Есть 50 категорий (примерно) и 140 недель (или около того), которые я пытаюсь чтобы сгуститься вниз. Я понимаю, что это много информации, чтобы конденсировать из 19mil строк, но я надеялся, что ограничение моего запроса до 10 строк, возвращенных, уменьшит количество времени?

И, если я не просто полный n00b, и это на самом деле не должно занять несколько минут, что именно не так с моим SQL?

Я погуглил, где оптимизация операторов, и, похоже, ничего не нашел. Все ссылки и объяснения более чем приветствуются.

Приношу извинения за такой пост новичка... мы все надо же с чего-то начинать, верно?

(*)использование SQLExplorer, моей IDE, реализации Eclipse белка SQL.

2 2
sql optimization db2

2 ответа:

Я не уверен, как сервер обрабатывает group by, когда в запросе нет агрегирующих функций. Основываясь на ваших ответах в комментариях, я бы просто попытался добавить их: 

SELECT
    ...,
    SUM(SalesCost) as SalesCost,
    SUM(SalesDollars) as SalesDollars
FROM
    ...

Оставьте остальную часть запроса как есть.

Если это не решит проблему, у вас могут отсутствовать индексы. Я бы попытался выяснить, есть ли индекс, где WEEK_ID является единственным столбцом или, где он является первым столбцом . Вы также можете проверить, есть ли у вас другой временной столбец (т. е. TransactionDate или что-то подобное) в той же таблице, которая уже проиндексирована. Если это так, то вы можете использовать его вместо этого в предложении where.

Без корректных индексов сервер базы данных вынужден выполнять полное сканирование таблиц, и это может объяснить проблемы с производительностью. 39 миллионов строк действительно занимают некоторое Не незначительное количество времени для чтения с диска.

Также проверьте, что тип данных WEEK_ID равен int или аналогичен, просто чтобы избежать ненужного приведения в запросе.

К избегайте сканирования таблицы в таблице Category, вам нужно убедиться, что Category_Number также индексируется. (Вероятно, это уже так, поскольку я предполагаю, что это ключ к этой таблице.)

2

Индексы на WEEK_ID, CATEGORY (и, возможно, CATEGORY_NUMBER) - это единственный способ сделать это действительно быстро, поэтому вам нужно убедить DBO ввести их.

0