SQL — это декларативный язык программирования, используемый для создания и манипулирования объектами в реляционных СУБД. Этот язык описывает что должно быть получено, но не описывает как это получить. Программист пишет запрос и (чаще всего) хочет получить результат от СУБД максимально быстро.

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

Поэтому оптимизатор — это ключевая часть СУБД, один из самых сложных элементов всей системы.

Для демонстрации работы оптимизатора практически во всех наших (и чужих) примерах на эту тему используются довольно скромные параметры: две-три таблицы, пара JOIN-ов, миллисекунды на выполнение запросов. А что будет, если загрузить оптимизатор десятками таблиц за раз? Как разные конфигурационные параметры влияют на производительность запросов с сотней JOIN-ов? И переживет ли это среднестатистический рабочий ноутбук? Ответы на эти вопросы — со схемами и графиками — вы найдете под катом!

При выполнении запросов современные СУБД используют стоимостную модель оптимизации — на основе сохраненных в конфигурационных файлах коэффициентов и собранной статистики высчитывают “цену” получения и объем результирующих наборов строк. При повторном выполнении запросов стоимость и селективность высчитываются заново. Можно выполнить запрос и посмотреть реальные значения этих параметров, однако, в процессе (стандартного) повторного планирования оптимизатор СУБД эту информацию никак не использует.

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

Это называется адаптивная оптимизация запросов, и данный способ оптимизации является перспективным. В некоторых СУБД такие технологии уже используются.

Компания Postgres Professional уже несколько лет работает над расширением AQO для PostgreSQL, которое реализует (в некотором виде) адаптивную оптимизацию. Работы еще ведутся, но уже есть что потестировать.

Сначала — подробнее рассмотрим предметную область оптимизации запросов.