Учимся оптимизировать SQL-запросы и понимать планы выполнения - ресурсы?


8

Я пишу все больше и больше SQL-запросов на работе (в основном Oracle 11g, но некоторые SQL Server 2005-2008) и начал создавать довольно сложные представления для остальной команды аналитиков.

Они в основном все работают довольно хорошо, но некоторые из них не так хорошо. Так...

  • Как мне научиться настраивать свои запросы?
  • Нужно ли учиться читать / действовать по планам выполнения?

А также...

  • Какие книги / сайты вы можете порекомендовать узнать о настройке SQL-запросов 1) в целом 2) специально для Oracle 11g?

У нас есть несколько хороших администраторов баз данных, но они слишком забиты, чтобы помочь нам настроить каждый запрос, который мы пишем.

Кажется, что большинство книг, которые я нашел на Amazon для Oracle, ориентированы на общую оптимизацию базы данных и / или были написаны 8-10 лет назад.

Спасибо за ваши советы :)


Ответы:


7

Я бы сказал, что изучение того, как понимать планы объяснения, является жизненно важным навыком, помогающим оптимизировать операторы SQL. Я нашел книгу Кристиана Антогнини « Устранение неполадок производительности Oracle» , в которой подробно описывается, как они работают, а также объясняется, как подойти к оптимизации базы данных. В то время как несколько лет, вы все равно узнаете много, что все еще актуально из этого.

Если вы станете более продвинутым, вы можете взглянуть на книги Джонатана Льюиса, но они более глубоки, поэтому, вероятно, не очень хорошая отправная точка. Основанные на затратах Оракул Основы в настоящее время довольно стар, но многое из этого по-прежнему актуально. Я еще не читал Oracle Core: Essential Internals для устранения неполадок , но он получил хорошие отзывы от сообщества Oracle.

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

Документация по Oracle SQL Monitoring: http://docs.oracle.com/cd/E11882_01/server.112/e16638/instance_tune.htm#PFGRF94543

Научиться настраивать запросы - это то, что потребует времени и практики. Несколько вещей, которые я узнал:

  • Напишите запросы, чтобы получить как можно меньше строк как можно скорее (например, вы не хотите полностью сканировать таблицу с 10 миллионами строк, если вам нужно только 100 строк из нее)
  • Убедитесь, что число строк, ожидаемое на каждом шаге плана объяснения (ожидаемого), совпадает с числом, возвращенным в фактическом плане выполнения. Когда эти порядки отличаются, вероятно, оптимизатор не выбирает «лучший» план.
  • Понимать принципы хорошей индексации: как они работают и когда их следует / не следует использовать при выполнении запроса ( Ричард Фут имеет очень глубокий блог, обсуждающий индексы в Oracle)

В основном вы научитесь писать запросы, смотреть на (ожидаемые) планы объяснения и сравнивать их с фактическими планами выполнения (либо путем отслеживания запроса, либо с помощью монитора SQL). Затем переписать запрос, добавить / удалить индексы и т. Д. И посмотреть, как это влияет на планы и сроки выполнения.


1

Поскольку вы ищете специфическую информацию для Oracle, я бы порекомендовал блог Ask Tom в Oracle. В общем, думаю, вы найдете совет не настраивать запрос. Вы получите хороший совет о том, как написать запрос, который оптимизатор может оптимизировать. Документация по Oracle также доступна онлайн , и я обычно ищу там актуальную информацию по Oracle. Я не работал с SQLServer, поэтому у меня нет никаких рекомендаций для него.

За последние несколько лет я не видел много нового в области оптимизации запросов. Большим изменением является устаревший оптимизатор на основе правил, с которым я едва помню, как работал. Однако я понимаю, что SQLServer по-прежнему использует оптимизатор на основе правил, поэтому понимание его правил может помочь.

Инструмент, с помощью которого вы можете отредактировать запрос, выполнить его и создать план объяснения, помогает понять, какие изменения приводят к успешному выполнению запроса. У меня были хорошие результаты с AquaData Studio, и мне действительно нравится его древовидная структура. SQL Developer должен делать то же самое.

Как и при любой оптимизации, вам необходимо иметь количественные данные о ее производительности. Затем вы можете определить, действительно ли вы его оптимизировали.

Как оптимизировать запрос частично зависит от того, как синтаксический анализатор строит и оптимизирует запрос. В большей степени это зависит от распределения запрашиваемых данных. В базе данных Oracle, если результирующий набор составляет четыре процента или более от таблицы и распределен случайным образом, сканирование таблицы обычно выполняется быстрее, чем индекс.

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

Для Oracle есть три настраиваемых параметра, которые могут существенно повлиять на производительность. Стоимость поиска индекса и данных взаимодействует, изменяя условия, при которых индекс будет использоваться или не будет использоваться. Эти два могут быть настроены для каждой сессии. Значения по умолчанию часто не оптимальны. Другое значение определяет, сколько альтернатив будет использовать оптимизатор. Увеличение этого значения часто помогает.

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


Возможно, вы захотите добавить сюда больше вещества. Это на самом деле граница "не ответ", как это в настоящее время.
JNK
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.