Проблема с производительностью на некотором простом запросе

Question

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

Таблица: ~ 100 миллионов строк
Статистика Собранная Еженедельно

пример:

SELECT c1,c2,c3,c4,TO_NUMBER(c5) 
FROM TABLE 
WHERE CODE = 3 AND 
     NUMBER IN (115,433,54542,435930,22565,3293029,3222) AND 
     DATE BETWEEN TO_DATE('01-01-2010','DD-MM-YYYY') AND TO_DATE('01-01-2015','DD-MM-YYYY') AND 
     AMOUNT > 1000 

В настоящее время существует индекс на код, номер и дату столбцов, которые используются, но запрос все еще требуется несколько минут. Также есть индекс только в столбце NUMBER, который был протестирован, и он работает немного лучше, но запрос все еще слишком медленный.
Таблица также разбивается на DATE по месяцам.

Поскольку существующие индексы не работают, я собираюсь создать свою собственную таблицу, в которой я могу свободно властвовать.

Мои идеи:
1) Создайте раздел или материализованный вид на CODE; половина таблицы имеет код = 3, поэтому я думаю, что это будет эффективно вдвое меньше размера таблицы.
2) ДАТА также сохраняется со временем; усечение всех дат и создание раздела таким образом может повысить производительность.
3) Создайте индекс на всех четырех столбцах, чтобы узнать, увеличит ли он производительность.

Это все, что у меня действительно есть. Любые другие предложения очень ценятся!

Answer 1

Ваш вопрос неясен по фактическому индексу, который находится на месте.

Для этого запроса лучший индекс находится на (code, number, date, amount).

Однако вы возвращаете данные за 5 лет из таблицы со 100 000 000 строк. Я не знаю, насколько избирательны другие столбцы, но это потенциально много возвращаемых данных. Это может объяснить проблему производительности.

Answer 2

Вы говорите, что таблица разделена на столбец DATE (предположительно, вы имеете в виду диапазонные разделы).

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

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

Итак, мой основной совет - научиться просматривать и понимать план выполнения. Вам нужно понять, что он делает, чтобы иметь реальное представление о том, что может сделать его лучше.

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

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

Возможно, добавление AMOUNT к индексу поможет, но это зависит от того, исключает ли AMOUNT > 1000 значительное количество строк.

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