Руководство по созданию эффективных запросов

 

продолжайте соединять таблицы одну за другой и каждый раз прове-
ряйте время выполнения и план выполнения;
 

убедитесь, что большие таблицы не сканируются многократно. Плани-
руйте запрос так, чтобы он читал большие таблицы только один раз, 
как описано в главе 6;
 

обратите внимание на группировку. В большинстве случаев стоит отло-
жить группировку до последнего шага, то есть нужно убедиться, что 
GROUP
BY
является последней командой в плане выполнения. Помните о случа-
ях, описанных в главе 6, когда группировку следует выполнять раньше, 
чтобы минимизировать размер промежуточных наборов данных.
н
о
 
Подождите
, 
это
 
еще
 
не
 
все
!
На протяжении всей книги мы настаивали на том, что оптимизация базы 
данных не ограничивается оптимизацией отдельных запросов; отдельные 
запросы не берутся из ниоткуда. Алгоритм оптимизации, описанный в пре-

---

Выводы 

273
дыдущих разделах, является руководством только для процесса оптимизации 
отдельного запроса или, скорее, правильного написания запроса с самого 
начала. Однако мы рассмотрели и несколько других методов.
Вот что еще следует учитывать:
 

параметры
– скорее всего, запрос, который вы оптимизируете, парамет-
ризован, то есть если вы имеете дело с идентификатором рейса, то это 
не фиксированное значение 
flight_id
=
1234
, а произвольный номер. 
Как мы обсуждали в главе 5, от конкретных значений может зависеть, 
какое из условий окажется самым ограничительным (например, статус 
отмены рейса будет более ограничительным, чем большинство других 
критериев);
 

динамический
SQL
– если от значений зависит, какое из условий явля-
ется наиболее ограничительным, или сами условия могут меняться – 
правильным подходом будет использование динамического SQL;
 

функции
– как обсуждалось в главе 11, сами по себе функции не улуч-
шают производительность и даже могут значительно увеличить время 
выполнения. Однако если необходим динамический SQL, без функций 
обойтись сложно;
 

изменения
в
структуре
базы
данных
– работая с запросами, вам может 
потребоваться выполнить команды DDL, от создания новых индексов 
до изменения схемы таблицы. Вам нужно будет поработать с адми-
нистраторами баз данных и системными архитекторами, чтобы опре-
делить, какие изменения можно реализовать;
 

взаимодействие
с
приложением
– ваш запрос выполняется приложени-
ем; производительность запроса может быть довольно хорошей, а об-
щая производительность приложения при этом – нет. Если вы и ваша 
команда решите использовать NORM или другой подобный подход, 
нужно будет поработать с разработчиками приложений, чтобы опре-
делить, что принадлежит бизнес-логике, а что – логике базы данных, 
как описано в главах 11 и 13.