Я также предполагаю, что вы используете Oracle. И я также рекомендую вам сначала ознакомиться с веб-страницей плана объяснения. Оптимизации много, но этому можно научиться.
Далее следуют несколько советов:
Во-первых, когда кто-то задает вам задачу оптимизации, он почти всегда ищет приемлемую производительность, а не конечную производительность. Если вы можете сократить время выполнения запроса с 3 минут до 3 секунд, не беспокойтесь, сократив его до 2 секунд, пока вас не попросят.
Во-вторых, сделайте быструю проверку, чтобы убедиться, что оптимизируемые вами запросы логически верны. Это звучит абсурдно, но я не могу сказать вам, сколько раз меня просили дать совет по медленному запросу, только чтобы узнать, что он иногда дает неправильные ответы! И, как выясняется, отладка запроса часто оказывалась и для его ускорения.
В частности, ищите фразу «Декартово соединение» в плане объяснения. Если вы видите это там, очень велики шансы, что вы нашли непреднамеренное декартово соединение. Обычный шаблон для непреднамеренного декартового объединения состоит в том, что в предложении FROM перечислены таблицы, разделенные запятой, а условия объединения содержатся в предложении WHERE. За исключением того, что одно из условий соединения отсутствует, так что у Oracle нет иного выбора, кроме как выполнить декартово соединение. С большими таблицами это приводит к падению производительности.
Можно увидеть декартово соединение в плане объяснения, где запрос логически корректен, но я связываю это с более старыми версиями Oracle.
Также ищите неиспользуемый составной индекс. Если первый столбец составного индекса не используется в запросе, Oracle может использовать этот индекс неэффективно или не использовать его вообще. Позвольте мне привести пример:
Запрос был:
select * from customers
where
State = @State
and ZipCode = @ZipCode
(СУБД не была Oracle, поэтому синтаксис был другим, и я забыл исходный синтаксис).
Быстрый просмотр индексов выявил индекс клиентов со столбцами
(Страна, Штат, ZipCode) в таком порядке. Я изменил запрос, чтобы прочитать
select * from customers
where Country = @Country
and State = @State
and ZipCode = @ZipCode
и теперь он работал примерно за 6 секунд вместо 6 минут, потому что оптимизатор смог использовать индекс с хорошим преимуществом. Я спросил программистов приложений, почему они не указали страну в критериях, и это был их ответ: они знали, что все адреса имеют страну, равную «США», поэтому они решили, что могут ускорить запрос, оставив этот критерий!
К сожалению, оптимизация поиска в базе данных - это не то же самое, что сокращение микросекунд от вычислительного времени. Это включает в себя понимание структуры базы данных, особенно индексов, и, по крайней мере, обзор того, как оптимизатор выполняет свою работу.
Обычно вы получаете лучшие результаты от оптимизатора, когда вы учитесь сотрудничать с ним, а не пытаетесь его перехитрить.
Удачи в ускорении при оптимизации!