Oracle DB читает запросы повышения производительности

Question

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

Например, есть таблица: Таблица (id, a, b, c, d, e, f) имеет 100k строк. Я запрашивая его следующим образом:

SELECT c, d, f FROM Table; 

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

Я думал об использовании PARTITIONS, но потом я подумал, что я просматриваю все строки (но не все столбцы), так что бы разделить на них помощь в этом случае?

Answer 1

Это немного для комментария.

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

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

И, наконец, 100 000 записей - это много записей для возврата в приложение. Я бы не удивился, если бы вы могли больше работать в базе данных и уменьшать количество возвращаемых данных.

Answer 2

В зависимости от типа/данных столбцов 100 000 записей не так много, чтобы их извлекать. Это слишком много, если вы извлекаете большие типы, например BLOB и CLOB. Ну, все зависит от конфигурации компьютера, на котором работает ваш сервер Oracle, но я предполагаю, что он имеет разумную конфигурацию.

Я выполнил запрос, как и вы в таблице Oracle с 386,843 строк ... он вернулся три NUMBER столбцы для каждой строки в 8,25 секунды ... учитывая количество данных, это не значит, что медленно ...

EXPLAIN PLAN говорит, что он сделал индекс FAST FULL SCAN, но по мере восстановления всех данных FULL TABLE SCAN также не должен представлять проблему с производительностью.

Я думаю, вы должны проверить два пункта:

1. Сколько клиенты будут выполнять это функционально в то же время? Допустим, 500 одновременного доступа ... это большая нагрузка на вашу базу данных/сеть, даже с некоторым кэшем данных ...

2. Разве сеть не откладывает вашу работу? Вы можете найти здесь проблему ...

Не можете ли вы просто загрузить данные «по запросу»? Извлекайте 5000 строк каждый раз. Это лучший способ справиться с вашим прецедентом. Таким образом, разбиение таблицы/индекса может оказать большую помощь.