Предположим, что у меня плохо выполняется запрос. Как вы обычно делаете оптимизацию sql? Каковы первые вещи, которые я должен посмотреть в плане выполнения запросов? Есть ли хорошая статья или книга об этом?Оптимизация и профилирование запросов Sql
Для того, чтобы использовать план выполнения (который представляет собой описание того, как база данных будет выполнять ваш запрос), необходимо понять, какие опции доступны для нее (база данных), и вынести решение о том, является ли выбор сделанный оптимизатором, был правильным. Для этого требуется много знаний и опыта.
Для работы я делаю (обработка ETL), производительность «проблемы», как правило, попадает в одну из двух категорий:
для (1), я должен решить, может ли я реструктурировать данные по-разному, так что я отсканировать меньше данных. Индексы редко используются, так как меня интересуют достаточно большие подмножества, чтобы сделать индексированный доступ медленнее, чем полное сканирование таблицы. Например, я могу сохранить горизонтальное подмножество данных (последние 30 дней) или вертикальное подмножество данных (10 столбцов вместо 80) или совокупность данных. В любом случае это уменьшит размер данных, чтобы увеличить скорость обработки. Конечно, если данные используются только один раз, я только что переместил проблему в другом месте.
Для (2) обычно я начинаю с проверки «Cardinality» (num rows) в верхней строке в xplan. Если я знаю, что мой запрос возвращает 5 000 000 строк, но он говорит 500, я могу быть уверен, что оптимизатор где-то испортился. Если полная мощность находится в правильном шаровом парке, я начинаю с другого конца и проверяю каждый шаг плана, пока не нахожу первую большую ошибку оценки. Если мощность ошибочна, метод соединения, вероятно, ошибочен между этой таблицей и следующей, и эта ошибка будет каскадироваться через остальную часть плана.
Google для «Настройка обратной связью по мощности», и вы найдете статью, написанную Вольфгангом Брейтлингом, которая описывает (в гораздо лучшем смысле) неприглядный подход. Это действительно хорошо читать!
Также не забудьте повесить около Jonathan Lewis Blog. если что-то о оптимизаторе Oracle он не знает, это не стоит знать. Он написал лучшую книгу по этому вопросу. Выезд Cost-Based Oracle fundamentals. Если бы я мог отправить одну книгу себе вовремя, это было бы так.
Expert Oracle Database Architecture от Tom Kyte (человек, стоящий за «Ask tom»), также является удивительным. Мое первое чтение этой книги было разочарованием, потому что я искал «советы по настройке» и не нашел ни одного.Во время моего второго чтения я понял, что, зная, как работает база данных, вы можете исключить целые классы проблем с производительностью путем «проектирования для производительности» с начала, а не «добавления» производительности в конце :)
SQL Tuning от Dan Tow, является еще одним удивительным прочтением основных принципов того, как точно можно определить оптимальный план выполнения. Это знание может использоваться как способ устранения неполадок плана выполнения (или принуждения оптимизатора к его выполнению).
Если вы сделали это так далеко, сейчас самое подходящее время, чтобы поиграть с подсказками. Не раньше, чем.
спасибо за то, что вы потратили свое время, чтобы объяснить вещи таким ясным способом. –
Performance Tuning Guide - отличное место для начала, но рейтинг Cost Based Oracle Fundamentals Jonathan Lewis - это каноническая ссылка на то, что делает оптимизатор и почему. Однако, в зависимости от сложности проблемы, основы CBO могут быть радикальным излишеством.
В качестве первого шага, если вы посмотрите на оценку мощности каждого шага в плане, полезно спросить, разумна ли эта мощность. Если мощности разумны, вполне вероятно, что Oracle выбирает наиболее эффективный план, и вам нужно искать другие подходы к настройке запроса. Если мощности сильно ошибочны, с другой стороны, вполне вероятно, что Oracle выбрала плохо выполняющий план запросов и что что-то о статистике необходимо скорректировать.
Performance tuning guide от Oracle было бы хорошим местом для начала.
Есть соображения на базовом уровне, чтобы заставить операторы SELECT работать хорошо (индексы, условия соединения, зависимые подзапросы и т. Д.), И есть дополнительные соображения, когда у вас есть «транзакционные» запросы (INSERT, UPDATE, DELETE). Вне сферы вашего вопроса, я бы предположил, это хранимые процедуры и триггеры. Это поможет опубликовать лучший ответ, если вы разъясните сферу своего интереса и что-то о вашем опыте/работе с SQL-программированием. – hardmath
Im ищет лучшие практики и полезные советы и рекомендации. Мой интерес - общий. Фон состоит в том, что время от времени мне приходится иметь дело с плохо выполняющими выборами, и я очень хочу узнать, как наилучшим образом справиться с этим. – Eduard
1) Вопрос только SQL в целом или Oracle? Существует много вещей, которые Oracle не может сделать или плохо, поэтому SQL, требуемый для Oracle, далек от стандартного SQL, который будет хорошо работать на любой другой платформе. 2) Заинтересованы ли вы в ответах более высокого уровня ... более низкие уровни дают меньшие улучшения, чем более высокие уровни. – PerformanceDBA