Oracle SQL Tuning Advisor с изменяющимся запросом

Question

У нас есть приложение на C #, которое будет искать в БД активность в нескольких таблицах. Пользователь может указать для поиска определенные критерии, которые в свою очередь основываются на базовом запросе SQL.

Этот запрос занимает очень много времени для выполнения, и мы хотели использовать Oracle Tuning Advisor для этого запроса. Наш вопрос, будет ли этот советник по настройке работать только для данного запроса?

Например, если мы выполняем настройку для приложений базового запроса (они не задают никаких критериев поиска):

SELECT Actv, FullName, DOB FROM Pers;

Применяется ли созданный профиль SQL только к этому утверждению? Что, если они задают критерии поиска, чтобы утверждение выросло до:

SELECT Actv, FullName, DOB FROM Pers WHERE Actv = 'Foo' AND DOB >= :Date;

Нужно ли нам создавать другой профиль SQL для этого запроса или оптимизатор использовал бы часть базового профиля SQL при создании плана выполнения?

Answer 1

Как правило, каждый запрос оптимизируется отдельно.Например, индексы, которые может предложить Советник по настройке, могут быть хорошими для некоторых запросов, но могут оказаться бесполезными для других запросов.То же самое можно сказать и о кластеризации кучи и разбиении данных.

Наивным решением было бы добавить все индексы, которые нужны всем запросам.Даже если это можно сделать, слишком много индексов замедлит все операторы SQL для изменения данных.То есть все INSERT с, UPDATE с и DELETE с станут медленными и дорогими.

Итак, что вы должны делать?Это зависит от вашего конкретного случая.Мое [очень личное] практическое правило не должно превышать 10 индексов на таблицу.

Конечно, если ваша таблица имеет высокую скорость обновления / вставки / удаления, я бы рассмотрел нижний предел.

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

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